Subject: RE: draft-costanzo-dns-gl-00.txt

From: "Al Costanzo" <[email-masked]>
Date: Fri, 30 Jul 1999 00:04:13 -0500

Andrew Brown Wrote:

    >>To me at least, this looks like an address.
    >
    >to me too.  i like it.  but i am just one (who is also using LOC here
    >and there).

Thank You!

Your not the only one who likes it, I have had positive reaction from a
number of people.

   >why don't you make up a set of patches to traceroute, the most widely
   >used little tool of the sort, and then see if people start using them.
   >the ratoolset has a version of traceroute that gives AS numbers with
   >each hop by looking them up in the arin database.  it's cute, but not
   >terribly useful to me.  and it also has to do an entire tcp
   >transaction to arin to get the info.  i'm not saying that's a bad
   >thing, but suppose you couldn't get there and were using traceroute to
   >find out why...  :)

This idea is under way, I am already pondering some tools for the Linux (os)
and giving them all away for free.  But this is contingent upon a positive
reaction to the idea from this WG.

-al

---

From: [email-masked] (Greg A. Woods)
Date: Fri, 30 Jul 1999 12:17:59 -0400 (EDT)

[ On Friday, July 30, 1999 at 00:04:13 (-0500), Al Costanzo wrote: ]
> Subject: RE: draft-costanzo-dns-gl-00.txt
>
> Andrew Brown Wrote:
> 

It seems to me that you folks are looking at the problem from too close
a perspective, or perhaps from the wrong side.

So far as I can see LOC is far superior to GL.  There are now a growing
number of on-line geographic information systems that make it possible
to easily hide its technical aspects.  It's all a matter of which way
you look at it.  My feeling is the database (i.e. DNS) should store the
most specific information possible, and LOC seems to be a good way to to
do this.  The applications (whether it is "query-loc", "host",
"traceroute", or some more sophisticated network management tool) can
easily use this highly flexible data to find the reference point in an
on-line viewable map, or even guestimate as to a more traditional form
address description.

I don't see any strong need to define another RR type just to include a
more traditional human-readable address in th DNS when such information
can be derived from the LOC RR data that is already defined.

Now if someone wants to define a standard for accessing public GIS
databases, then that's another thing all together!  ;-)

BTW, to all you folks who don't like LOC because it gives the physical
location of your hardware, well strictly speaking that's your fault.  If
you don't want your physical location to be known then either don't
include a publicly query-able LOC record in your DNS, or else
alternately just specify the location of the nearest branch office or
whatever, or even just put the city's co-ordinates in there with a large
enough size/precision field to encompass your POP, or whatever.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <[email-masked]>      <robohack!woods>
Planix, Inc. <[email-masked]>; Secrets of the Weird <[email-masked]>

---

From: Edward Lewis <[email-masked]>
Date: Fri, 30 Jul 1999 09:51:06 -0400

>reaction to the idea from this WG.

IMHO, I think you are putting the cart before the horse.  Getting an RFC
published to define a RR does not guarantee that anyone implements it.  No
one is bound to implement any IETF standard.

Consider this snipet of history with DNSSEC.  There was a good deal of work
from at least December '94 until the December '97 IETF in the DNSIND WG.  A
few people worked feverishly to generate draft after draft, but received
little to no WG comment.  I once put out a cry for comments on the mailing
list and received fewer than 5 responses.  I was convinced that DNSSEC was
withering away.

But then, off the WG track, "forces emerged" to integrate software that
implements DNSSEC into the ISC BIND.  Now that DNSSEC is in BIND, there is
a rising demand for it.  Suddenly, it seems, there has been a lot of
renewed WG interest in resuming the work started a few years back.

WG's (shouldn't) go around looking for work to tackle, they are limited in
lifetime.  WG's are formed to tackle an already identified problem,
hopefully one with a least one prosposed solution.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda

Opinions expressed are property of my evil twin, not my employer.

---

From: "Al Costanzo" <[email-masked]>
Date: Sat, 31 Jul 1999 12:24:44 -0500

>do this.  The applications (whether it is "query-loc", "host",

Greg, does it really do a better job?  Is it more precise?

Please tell me how to use LOC to define foobar.nasa.gov which is located on
the new multinational space station in orbit around the earth?

I have been told it cannot be done with LOC.

GL can do it in a snap. SO how is LOC 'far superior'  or does it just appear
to be better because you have to do alot more work to use it :-)

   >can be derived from the LOC RR data that is already defined.

Its not just a duplication of information that LOC already provides. I would
not be wasting my or this WGs time.  GL is able to define a location
anywhere NASA has assigned an Astronomical Location to as well as the good
ol' planet Earth.

Now if your going to make an improvement on something; I thought, let's make
it easy to use!  Look what web sites did for the Internet!

GL is not less precise than LOC or GPOS if you fill in the H.L. completely
it can pinpoint the exact location right down to the building esp in the
U.S.  Altitude is irr. since it may be cross referenced from other sources
since we know the exact lat and lon from the H.L. assuming it is fully
qualified.

   >enough size/precision field to encompass your POP, or whatever.

I agree with you here and this can been done with GL as well.

-al

---

From: Mats Dufberg <[email-masked]>
Date: Sat, 31 Jul 1999 23:30:08 +0200 (CEST)

The the aim of the GL record is to provide information of the physical
position of a server. The definition of the record assumes that the postal
zip code is a good approximation for the physical approximation. The zip
code is not defined for physical position of the recipient of postal mail,
but for the ease of distribution of postal mail.

Why should positioning of a server be based of another coding system with
a different purpose? If the aim is to give the position of the server, use
a code system that is meant for that.

I see no reason to include GL records. If human readable information is
needed, use TXT records.

Mats

-----------------------------------------------------------------
Mats Dufberg                                    [email-masked]
NIC-SE AB                                        +46-8-545 857 06
Box 5774                                    fax: +46-8-545 857 29
SE-114 87 Stockholm                         http://www.nic-se.se/