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

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.

--
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: Ó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)