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

["Al Costanzo" <al@akc.com>]

Greg A. Woods wrote:

>> Greg, does it really do a better job?  Is it more precise?
>
>It is as precise or imprecise as the publisher wishes it to be!  ;-)

'Can be' would be better verbage.

You state that all you need is a cheep portable GPS to use LOC.

Is there any other DNS RR that requires a non-network oriented device to use
a DNS entry?

Requiring people to need a GPS to use LOC (in my mind is ridiculous)

To complete my example; to define the location of the space station, you
would simple use the NASA designated astronomical location/designator for
it.

 >LOC RRs obviously cannot precisely locate any mobile object, be it
 >moving over the surface of the Earth, under the oceans, or above in an
 >aircraft or spacecraft; at least not in their current form.  Indeed
 >defining the exact position of a mobile object in a semi-static database
 >seem to be somewhat of an oxymoron (though I realize that even a
 >non-geo-synchronous orbit is perhaps somewhat of a special case).

This is exactly one of the problems GL addresses.  Although the entry for
the Space Station in the DNS would remain static.  The external NASA
database does not an external NASA interface does the rest of the work just
fine without changing DNS entries every five nano-seconds.

Now, why should we burden the DNS with the exact location of the space
station? Someone who really needs the information will be able to plot an
exact location without DNS, All the DNS should be concerned with is (at
least in space, what the designator is)

You do not need to know its location in orbit, its height, its altitude etc.
because NASA does and NASA has designated a symbol for it.  Just like you
may not know how to drive your car to a location you mail a postal letter
to.   The post office knows where it is.

Using a gigantic large sphere will not pinpoint the location of the object
as Elz pointed out. You just know its out there, and there is no designator
to have an external reference for/to.

_BUT_ by a mere GL entry with the astro designator that NASA has defined. If
one did want to track the object you could by cross matching the information
in an external database that had the co-ordinate information.

The IETF has a reputation of creating things that are not user oriented. It
is IMHO that LOC is definitely one of them.


Is the altitude important? No
Longitude? No
Latitude? No


 >According to my reading of RFC 1876 it's possible to describe any
 >geo-synchronous body at any altitude up to 42849672.95 meters (though I
 >suspect orbital mechanics rule out quite a bit of that range!  ;-).

 >However as Mr. Elz points out there's no problem with using LOC RRs to
 >define a large enough sphere to encompass the potential movements of
 >anything directly related in any way to the Earth (though my knowledge
 >of this stuff is somewhat limited and I'm not entirely sure that the
 >maximum sphere is large enough to cover the space station's orbit).

By doing this though the location becomes ambiguous, does it not?

 >Lastly I think it's important to note that LOC RRs include a version
 >number, and that's all that's necessary to properly extend them to
 >specify any additional co-ordinates necessary to pinpoint a network
 >device on any orbiting satellite or spacecraft, or indeed on or near the
 >surface of any body in the Solar System or beyond.  One could even tag a
 >mobile device that's able to report its current position through some
 >secondary protocol.  One could even reserve a version number to specify
 >a form of the record that includes arbitrary data such as a postal
 >address.


Well if you update LOC to include these things you wind up with something
that looks like
GL ;-)

 >I'm not necessarily opposed to the proposed GL RR, but I don't really
 >see how it'll solve any problem not already solved by LOC RRs, including
 >their usability.  Ultimately LOC RRs seem far more flexible to me and
 >thus far more useful.

To answer your question:

1. You do not need a GPS to use the RR.
2. The RR is readily understandable
3. It supports any location in the 'known' universe
4. It is just as precise as any RR that uses Longitude and Latitude
5. It is most likely more precise that LOC and GPOS after you factor in
'User Errors' of the people using a GPS.  Someone using a GPS could not even
find my house using the thing, he was two blocks off and owned the GPS for
two years.  Precision of GPSes varies greatly.

I do not see how LOC is anymore flexible than GL.  If you are talking about
not giving your exact location away, you would do this with GL by using only
the city (or state) name in the quoted string, anything more ambiguous and
why bother putting it in.

>BTW, I think your definition of "usability" is slightly backwards.  You
>seem to be trying to aim more towards a format that's easy to publish,
>but not necessarily easy to use.

I think not. Is it easier to use a GPS to factor in co-ordinates to figure
out you house address or just write down your house address like you always
do? :-)

>LOC RRs, while not trivial to use, are
>(I think) much easier to use from a computer programming point of view.

But we should not be looking at this always from a computer programmers
point of view.  I know alot of systems administrator positions (who BTW take
care of the DNS) that are not programmers but rather Administrators that
have never done a lick of programming.

>Indeed I don't see any hassle with "using" LOC RRs from the point of
>view of publishing them these days either, what with nearly every
>hardware, electronics, and outdoor-sportsman store in at least all of
>North America selling inexpensive hand-held GPS receivers!  ;-)

What other DNS entry requires you to go to radio shack to use it? ;-)

You are also under the fallacy that all GPSes are 100% accurate, Popular
Science rate them a while back. they are not all equal. Therefore accuracy
varies.

Your zip code and postal address is not some arbitrary thing a little radio
shack gizmo tells you is right.  your postal address IS RIGHT all the time.

Therefore I must conclude that GL is far more superior to LOC.

>I'd be
>willing to bet a beer that every hostmaster in North America knows at
>least one person who either owns a GPS receiver, or knows someone who
>does.

Knowing someone and owning it yourself are two different things.

Is the IETF going to send out one GPS for free to anyone who want to use LOC
but has no access to a GPS?

GL solves this and other problems and IMHO obsoletes LOC.


Sorry to all that worked on the LOC rfc but truthfully GL is much better for
all the reasons listed above.

BTW: a new version of the draft with some corrections and suggestion from
this list will be out this week.

Regards to all,

Al Costanzo