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

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
> 
> 
> 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.
> 
> 
> 
> ----- Original Message ----- 
> From: "Rosen, Brian" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, February 19, 2004 10:55 AM
> Subject: New I-D on using DNS to support Emergency Calls
> 
> 
> > 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/>
> >
> 

--
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 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: Jim Reid <[email-masked]>
Date: Thu, 19 Feb 2004 19:58:13 +0000

This is a profoundly silly draft.

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?

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.

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.

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?