Subject: New I-D on using DNS to support Emergency Calls

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 19 Feb 2004 10:55:38 -0500

Please have a look at
http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt

Yeah, I know.  Flame away.  I think it's a pretty good idea anyway :)

Brian

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Al Costanzo" <[email-masked]>
Date: Thu, 19 Feb 2004 12:20:31 -0500

Dear Brian & everyone on the namedroppers list,

When I tell you I total agree that this information needs to be in the DNS
for a number or reasons:

1.911 as you mentioned
2.Credit Card Verification Processing
3.New Anti-Spam Legislation

To add just two more.

After reading your draft, I disagree on how the information is to be
inserted into the RR.

The address needs to be listed in the RR as it was a postal address. The
reason for this is ease of use. Everyone know their own address but not mank
know thier geographic location.

I welcome you and everone to help me come up with a solution in this matter.
A document I just revised is attached to this email. Not sure if the list
server allows such things.

I am not a proud or I need it done my way or I want the glory for the RFC
kinda guy.

I see a problem that needs to be addressed, I think the solution I presented
is the best solution, but if anyone thinks this idea can be tweaked or you
want to co-author the work and work on this solution with me, please feel
free to let me know. I however do not want the RR to use Log and Lat as
reference points.

The draft has been submitted as: draft-costanzo-dns-gl-06.txt  but I am sure
it is not listed in the I-D directory yet.

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 19 Feb 2004 13:24:46 -0500

As a practical matter, you rarely type your location into a form to
determine
where you are.  Rather, various service providers, enterprises and automated
mechanisms determine your location from a variety of information sources.
Therefore, the idea that the form of the entry has to exactly match a postal
address is not true.  Further, for emergency response, your postal address
is
often not your response address, for example when the post office that
serves
you is not the municipality where you are located.  In my own case, I live
in
Pine Township, Allegheny County, but my postal address is Mars, PA 16046.
Mars is a nearby town, in Butler County.  For emergency dispatch, it is 
essential that the ERC serving Pine Township get the call, and that for
dispatch, that the address is a Pine township address and not a Mars
address.

Also, the delegation properties of the DNS exactly match what is required to
provide location to the precision of a room. Using the naming hierarchy to
permit delegation of an address to a building owner, and thence to a suite
owner, who enters room level data in his entry is particularly useful.

And, the postal zone boundary does not align with the ERC boundaries, and
does not align with municipal boundaries, which further complicates 
populating the database.

For these reasons, I believe my suggestion is a better one.

Brian

> -----Original Message-----
> From: Al Costanzo [mailto:[email-masked]]
> Sent: Thursday, February 19, 2004 12:21 PM
> To: Rosen, Brian; [email-masked]
> Subject: Re: New I-D on using DNS to support Emergency Calls
> 
>

---

From: "Al Costanzo" <[email-masked]>
Date: Thu, 19 Feb 2004 13:37:21 -0500

Hi Brian,

A complete Zip+4 points to your exact location.  There is no rule what
address you use in the field, and there is a cmment area as well.

My opinion is ased on the fact that hardly anyone uses the LOC RR and I
think it is because it requires a Log & Lad indication as points of
references.

IMHO postal addresses solve this, but its only my opinion.

Al

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 19 Feb 2004 13:43:40 -0500

Al

A Zip+4 can cross a township boundary (mine does).  It can cross an ERC
response boundary (also true here), and it can cross a state boundary (rare,
but true).  Postal codes are for the post office, and they don't reflect
anything other than convenience for the Post Office sorting and delivery
people.  In many countries, they don't even have postal codes.  As such,
I don't think they help anything but delivering snail mail.

Brian

> Sent: Thursday, February 19, 2004 1:37 PM
> > Therefore, the idea that the form of the entry has to 
> exactly match a
> postal
> > Also, the delegation properties of the DNS exactly match 
> what is required
> to

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 19 Feb 2004 14:12:27 -0500

Sorry, I did not understand your goal well enough.

Then again, I don't think you can meet your goal with the DNS.
The computer which you are sending or receiving email or entering 
credit card information probably does not have an externally available 
DNS entry, and the "nearest" (in the Internet sense) one that does 
is not very close to you (in the postal address sense) in almost 
every case.  

Brian

> Sent: Thursday, February 19, 2004 1:53 PM
> Brian,
> Hmmm... In the case of 911 records my draft  may not help 
> then (if you feel
> you must put in your postal address and not the desired 911 location).
> 
> But this draft helps the other two points that it actually 
> was written for.
> To keep track of the physical address of the location of the 
> machine that
> the A record is associated with.
> 
> Or the location that the ISP would like to have it on record.
> 
> The dradt was written to help prevent credit card fraud by 
> having a fall
> back for non-mobile computers to help verify the address entered.
> 
> Please note that the draft I submitted support precision so 
> for example you
> could just enter the country or country & state, etc, for a 
> less precise
> location for Privacy concern.
> 
> Because this draft was written to help prevent SPAM as well 
> as help with
> credit card processing, it may be that it cannot help you 
> with your need.
> 
> Unfortuantely, Lat & Log co-ordinates do not help me with the 
> needs I am
> trying to address.
> 
> Best Regards,
> 
> Al
> Sent: Thursday, February 19, 2004 1:43 PM
> > response boundary (also true here), and it can cross a 
> state boundary
> (rare,
> > > > where you are.  Rather, various service providers, 
> enterprises and
> > > automated

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 19 Feb 2004 15:22:02 -0500

Thank you for your direct response to the issues raised by the draft
 
> - It mixes the information you need to find the number to the correct 
> ERC with information you need to send to the ERC. In Sweden for 
> example, the resolution is on city boundary basis, but even 
> if you pass 
> the call to one such ERC, the destination E.164 you use is in reality 
> only a hint to the "virtual ERC" which is covering Sweden where the 
> call is coming from. So, it seems in the US (and this draft) 
> you try to 
> solve a problem which for example we in Sweden have solved by forcing 
> the ERC's in the country to solve the problem among themselves?
You don't know that VoIP routing will be done the same way, but suppose
that it is.  The proposal allows the ERC entry to be in se.sos.arpa.
It could also be more complex.  For example, Stockholm could have
calls come directly to it (stockholm.se.sos.arpa, I don't know if you
have a "county" equivalent), with the rest of the country sending calls
to the ERC NAPTR at se.sos.arpa.

You still need to be able to dispatch to a room based on a lat/lon, 
where the lat/lon is known, and you need to be able to have a 
"standardized" naming convention for a civil address when that
is known, which is what the proposal provides.

> 
> - What information is passed to the ERC is, I claim, by far more 
> important than finding the right ERC. Yes, YMMV (see above).
Yes, my mileage varies quite a bit; finding the right ERC is the
first step, and has to be done well.  If I am in Stockholm,
but connecting to Marconi's VoIP system through a VPN tunnel,
then I really want the call to go to Stockholm's ERC and not
Pittsburgh's ERC.

> 
> - Doing a width-first *search* in DNS is to be honest a plain 
> bad idea. 
> The operation doesn't exist (part from zone transfers of 
> course), and I 
> would suggest going to a specific protocol which can do this.
Yes, I clearly understand the weakness here.  The text does
discuss this.  You need both mappings.  Either you use the zone
transfer idea, caching the result, or we really create both mappings
in the DNS.

Henning Schultzrinne has made a suggestion that we use a PTR
RR for each leaf below any point in the tree.  It makes the entries
bigger, but fixes the problem.

> 
> - When you define a new RR type for this, why not "just" tag 
> the URI to 
> the data just like the corners of the polygon which is defining the 
> area?
This is possible.  The weakness is that you can't depend on the URI
to be available when you make the call.  This forces every proxy that
routes emergency calls to off-line create a complete database by
visiting the requisite URIs.  The proposal envisions that you cache
the entries you need most of the time, but are able to use the DNS
for "odd" calls, like the roaming VPN user.

> 
> - The overall problem for ERC dispatch services is as far as I know 
> that the person/tool/whatever which issue the call don't know 
> where he 
> is. So, the "network" have to tell the ERC where the call is coming 
> from, and _that_ is the real problem to solve. If you know this, I am 
> sure the ERC can use whatever database needed to map to whatever 
> coordinates they use this tuesday.
Yes, we are working hard on the problem of determining your location,
and there are a number of drafts in progress on this subject in progress.
All of the drafts end up with ONE of civil or geo.  They don't end up
with the URI of the ERC serving the location, and as my draft points out,
you often need both forms.  Therefore, yes, we need to solve the
"where am I" problem, but we also need to solve the "what is the URI
of the ERC serving my location" and also the conversion between geo and
civil.  We also need a standardized enumeration of legal civils (the
Master Street Address Guide").  The proposal solves all three of these
problems.

> 
> - The database normally used for ERC coordination is extremely 
> sensitive information, at least in Sweden. It can for example map the 
> coordinate of E.164 numbers to geographical location, 
> _including_ E.164 
> which are protected, used by people with protected (changed) identity 
> etc. If this data get out on the street.... The database 
> access must be 
> extremely protected and only possible to access by very 
> special access 
> codes etc. Security implications are enormous. Yes, in Sweden a telco 
> is required over the SS7 network to _always_ pass the caller 
> id of the 
> calling party to the ERC's. That's a very special function in Sweden 
> and overrides whatever other rules there might be (like *NEVER*EVER* 
> passing the caller ID of people with protected identities to third 
> parties).
Yes, location information is sensitive.  Address information is not;
it is public information.  You cannot have an unlisted house.
The proposal does not make any connection between an E.164 and a
location, nor does it associate a name, or any other personal information
with a location.  

As the draft discusses, there is a concern over interior building
information, which is often not public, and proposes a solution for that.

> 
> Etc etc...
> 
> So, there is a lot of work to do in the area of 911/112 calls, and I 
> think very very few (if any) have to do with DNS.
Well, there is definitely a lot of work.  And there is already a lot
of effort.  However, it does no good to solve most of the problem,
one has to solve all of it, and these three problems do not currently
have any standardized solution.

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 19 Feb 2004 15:48:13 -0500

> This is a profoundly silly draft.
Well, I knew I was going to get flamed, but I don't give up easily.
I do appreciate your effort to explain why you feel as you do
rather than just stopping here.

> 
> First of all, the DNS already has a perfectly good RR type -- albeit
> one that's rarely used -- for specifying location information. There
> seems no point in replacing the the LOC record or augmenting it with
> this proposed POLY record. What does this POLY record do that can't be
> done already with a LOC record?
Please read the draft.

There are several problems the draft addresses, but they all deal with
the issue that you know your location as a point, but have to determine
which defined BOUNDARY that point lies within.

The ERC that serves a specific location is defined by a boundary, not
a point, or a point and a radius.   To determine which ERC serves a
location,
I have to know the boundary, and compare the location point to the boundary.

The same is true for dispatch.  A street address is not a point, it is 
a boundary.  A lot of points lie within the boundary.  You cannot compare
points (it's not a nearest neighbor problem).  The POLY defines a boundary,
which you intersect with a point.

> 
> Secondly, the proposed naming scheme is arbitrary and poorly
> structured. This means that it will be very hard in practice to
> generate appropriate query names that would elicit meaningful
> responses from the DNS, assuming it was populated with that
> information. For instance, it doesn't say anything about place names
> that sound the same but are spelled differently (or vice versa); or
> cases where a town or city has two or more streets by the same name
> (there are umpteen "High Streets" in the Greater London conurbation);
> or where white space and punctuation would be significant (King's Road
> vs Kings Road or "Sunny Vale" vs "Sunnyvale"; etc, etc. The naming
> scheme doesn't take account of location information which includes the
> character ".": ie "Room 11.2, Building Foo....". It also doesn't take
> account of places that change their name. Or have different names in
> different national languages. For instance, the Belgians have 2 names
> for Brussels depending on whether Flemish or French is used.
Actually, the precise point of the naming scheme is that it DEFINES the
"correct" way to express an address.  Each ERC faces this problem, and
its solution is that it creates a "Master Street Address Guide" which
enumerates all legal addresses.  

The draft is not particularly clear on how you deal with a location that
is reported one way, but is stored in the sos.arpa tree another way.
Generally, the idea is that the location generator uses the DNS to
validate that its idea of address matches the address in the sos.arpa
tree BEFOREHAND.  The proposal is that the DNS is "authoritative" 
(gotta love it).  

Its conceivable to put alternate forms of address in the tree with 
CNAME direction to the "real" address.  There is no problem with having
two addresses that have the same boundary as long as the ERC is capable
of dispatching based on either.

> 
> Thirdly, this draft takes no account of locations that don't readily
> correspond to a postal address (or equivalent). Or when the calling
> party is lost. For instance when the caller is in a boat or light
> aircraft or trekking in some mountain range. What sort of name would
> be looked up for a sinking ship in international waters? For bonus
> points, repeat this exercise when the ship is equidistant between two
> or more countries.
Actually, the proposal deals with this issue quite well.  One puts the
area served by an agency within the poly describing the service boundary,
as well as the boundaries of the entities above it in the tree.  The
proposal
already explains that it is even possible for two countries to claim
the same area.

I did not deal with a service area that is not claimed by any nation.
I think there are pretty straightforward ways to deal with it.
I'll give that one some thought.

> 
> Finally when an (approximate) address/location is known, there would
> be no reason to look up its latitude/longitude in the DNS in the first
> place. Or am I missing something?
You are missing several things:
1) You cannot in general, determine the serving ERC from an address
represented as a civil because the boundaries are not simple.  Generally,
boundaries of the ERC is in fact a set of lat/lon points, although they 
are sometimes described in civil terms that don't easily lend themselves
to automated mechanisms (Highway 1 from First to Fifth), but are
straightforwardly convertible to lat/lon and then used in a point/boundary
intersection, as I propose.
2) You need a standardized representation for civil address (the MSAG)
4) The address does not tell you what the responders that serve
that address are, and the ERC boundary does not match the responder
boundaries often.  There could be other solutions to this problem, because
it is internal to the ERC, but the proposal easily handles it.

---

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Thu, 19 Feb 2004 16:27:14 -0500

>rather than just stopping here.

90% of this draft is clearly out of scope for this mailing list,
and the 10% in-scope depends on the other 90% so I'm ruling this
discussion out-of-scope.

Please take this discussion somewhere else, feel free to
announce where follow-up is supposed to go.

         Olafur (DNSEXT WG co-chair)