Subject: LOC et.al. (what, no Ton'Loc?)

From: [email-masked]
Date: Mon, 2 Aug 1999 11:22:12 -0700 (PDT)

> 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

RFC 1876  already has a -very- cool method for injecting ambiguity.
>From the RFC:

SIZE         The diameter of a sphere enclosing the described entity, in
             centimeters, expressed as a pair of four-bit unsigned
             integers, each ranging from zero to nine, with the most
             significant four bits representing the base and the second
             number representing the power of ten by which to multiply
             the base.  This allows sizes from 0e0 (<1cm) to 9e9
             (90,000km) to be expressed.  This representation was chosen
             such that the hexadecimal representation can be read by
             eye; 0x15 = 1e5.  Four-bit values greater than 9 are
             undefined, as are values with a base of zero and a non-zero
             exponent.

             Since 20000000m (represented by the value 0x29) is greater
             than the equatorial diameter of the WGS 84 ellipsoid
             (12756274m), it is therefore suitable for use as a
             "worldwide" size.

You don't -have- to go to the nearest coordinate intersection for ambiguity.
....

-- 
--bill

---

From: Robert Elz <[email-masked]>
Date: Wed, 04 Aug 1999 00:55:42 +1000

Date:        Tue, 3 Aug 1999 01:28:27 -0400 (EDT)
    From:        [email-masked] (Greg A. Woods)
    Message-ID:  <[email-masked]>

  | However as Mr. Elz points out

That was Mr Manning, not I... (which doesn't make it any less true)

  | 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.  LOC RRs, while not trivial to use, are
  | (I think) much easier to use from a computer programming point of view.

That is a very important point.   in the DNS we have generally stretched
quite a long way in exactly the other direction - make the person publishing
the data do a bit of extra work, so the clients don't need to.  The
expectation must be that many clients will query the RR, having them all
do a bunch of extra work (like finding some postal code to real location
database, and querying it) just to save the server (or its maintainer)
from doing that once, is completely the anthesis of all the DNS normally
sets out to achieve.

There are a also a lot of (comparativly minor) problems with the draft as
it stands tat would need to be fixed were it to ever be published as anything.
But it isn't worth spending effort on getting those fixed while the general
question remains as to whether there's any point in defining this RR at all.

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 04 Aug 1999 00:55:42 +1000

kre

---

From: [email-masked] (Greg A. Woods)
Date: Tue, 3 Aug 1999 01:28:27 -0400 (EDT)

[ On Saturday, July 31, 1999 at 12:24:44 (-0500), Al Costanzo wrote: ]
> Subject: RE: draft-costanzo-dns-gl-00.txt
>
> 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!  ;-)
 
> 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.

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!  ;-).

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).

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).

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.

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

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.

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.  LOC RRs, while not trivial to use, are
(I think) much easier to use from a computer programming point of view.

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!  ;-)  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.

-- 
							Greg A. Woods

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

---

From: [email-masked]
Date: Tue, 3 Aug 1999 10:18:28 -0700 (PDT)

> '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)

	No, GPS is not required.  (I'll note that GPS may help and
	there are estimates of low double-digit millions for the number
	of deployed GPS chips in the next 2-3 years or one GPS device
	for every two computing devices.)

> To answer your question:
> 
> 1. You do not need a GPS to use the RR.

	Either LOC or the proposed GL.

> 2. The RR is readily understandable

	perhaps - I have trouble with many addresses in China, India
	and Africa.  Often they are a single building in the
	community and people must go to that location for postal mail
	delivery. There is no way of id'ing a each specific building for
	postal service.  I can't get the accuracy that I want w/ GL. 
	I can with LOC.

> 3. It supports any location in the 'known' universe

	Not really, unless I can code "Somewhere over there" or 
	"To the Left!"

> 4. It is just as precise as any RR that uses Longitude and Latitude

	Nope.

> 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.

	See the statements above on the lack of requirement for GPS.

> 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.

	Numbers tend to be less cryptic than alpha or iconic strings 
	that most people use for expressing location.

	RU14-18, Rack8, Room 820, 4676 Admiralty Way, Marina del Rey, CA. 90292

vs
	33 55 59.318 N 118 25 55.223 W 10M 20M

	If you are are native Korean reader, which makes more sense?
	
> 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.

	But won't tell me where on the King Ranch I am (side note to
	non-US readers, the King Ranch in Texas has its own zip code and
	covers thousands of square miles.  And of course postal codes never
	change. Just like telco area codes.

> Al Costanzo

--bill

---

From: "Al Costanzo" <[email-masked]>
Date: Tue, 3 Aug 1999 10:44:52 -0500

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

 >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

 >maximum sphere is large enough to cover the space station's orbit).

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

 >a form of the record that includes arbitrary data such as a postal

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

To answer your question:

>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

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.

>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.

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

>I'd be

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

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 03 Aug 1999 13:53:01 -0500

(I hope I don't regret speaking up in this thread, but ...)

> > I have been told it cannot be done with LOC.

No problem.  You choose the accuracy you want, down to 8000 meters as
a minimum, then you set the TTL on the LOC record so the space
station moves by less than that amount within one TTL, and then I
think the rest should be obvious.

				Matt

---

From: Terry Lambert <[email-masked]>
Date: Tue, 03 Aug 1999 12:51:48 -0700

Greg A. Woods wrote:
> 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!  ;-).

Not for geosynchronous objects, it won't.  They can all be
addressed, if they are inside the sphere.

[ ... ]

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

Well, I can imagine two scenarios, off the bat:

1)	"On board space station MIR,
	 Module three"

	Sure it's not a great postal address, but it's
	enough of one that, with independent information
	about orbital mechanics, you could locate the
	system.

2)	"In the trunk,
	 1974 Buick Electra,
	 Utah License CSE 245"

	Again, not a great postal address, but enough to
	locate the system, relative to the Buick, which
	you might, again, do with external information.

Not that these are really very likely, IMO...

-- Terry Lambert
-- Whistle Communications, Inc.
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: [email-masked] (Greg A. Woods)
Date: Tue, 3 Aug 1999 15:48:03 -0400 (EDT)

[ On Tuesday, August 3, 1999 at 10:44:52 (-0500), Al Costanzo wrote: ]
> that looks like GL ;-)

Well, actually, no.  If you use the version number not only to indicate
obsolete record formats but also to indicate content features then you
end up with a much more interesting and powerful format (IMHO), one that
could easily be extended in a compatible manner to fulfill all the
real-"world" requirements one might ever imagine for defining the
physical location of a network device; but one that at the same time
remains compatible with the currently deployed LOC RRs.

> point of view.

Au contraire!

>  I know alot of systems administrator positions (who BTW take

I'll go out on a bit of a stretch here and claim that the DNS is most
definitely not meant to be used directly by end users, or even
necessarily by administrators.  Even if that were its original intention
one can clearly see from the way people do use it today that it would be
impossible to expect as much expertise in the average network
administrator, never mind in the general Internet user population, as
would be necessary to use it directly in all cases.  A growing number of
admins and almost all end users are shielded from direct contact with
the DNS by various applications.  Whether this is good or bad is, for
this discussion, irrelevant.

In any case DNS records, including LOC-style RRs, must be most friendly
to computers and computer programs which do need to use them directly.

If network administrators are indeed having a hard time figuring out
what to enter in a LOC RR, even with the help of a GPS reciever at hand,
then the correct solution is to write an application that will help them
generate such records.  We should most definitely not be defining a
replacement RR just for the sake of the making it easier for network
admins to publish location information in the DNS.

If the problem with LOC is that it cannot specify the position of a
moving body such as spacecraft, or that it cannot specify a location on
another moon or planet, then the best solution is to re-specify or
enhance it while maintaining as much bacwkard compatibility with the
current format.  In my opinion the version number carried in the LOC RR
is sufficient for enabling such enhancements.

The LOC RR does exist as a specified format, and is already being used
successfully in various applications.  I don't think there's anything
fundamentally wrong with it in the context it was seemingly intended to
be used.

> Science rate them a while back. they are not all equal. Therefore accuracy

I never said anything of the like.  A GPS is simply one handy way of
getting geographic co-ordinates that are perhaps somewhat more precise
than those one might caculate using the co-ordinates of the nearest city
hall or airport (either of which are usually easily found without a GPS).

Besides, there are now many other ways of looking up a geographic
location suitable for publishing in a LOC record without having to use a
GPS.  For example I can find the location for the published postal
address of your domain name (using whois and mapblast.com) as
approximately 40.6653N/74.2664W, which together with the default LOC
precisions will effectively position it on a map within the average area
usually covered by a zip code in a metropolitan area.

I'll second Bill Manning's answer (under the subject "Why GL") to the
rest of your posting.

-- 
							Greg A. Woods

---

From: "Al Costanzo" <[email-masked]>
Date: Tue, 3 Aug 1999 23:43:29 -0500

Robert Elz Wrote:
     |
     |   | 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.  LOC RRs, while not
     | trivial to use, are
     |   | (I think) much easier to use from a computer
     | programming point of view.
     |
     | That is a very important point.   in the DNS we have
     | generally stretched
     | quite a long way in exactly the other direction - make
     | the person publishing
     | the data do a bit of extra work, so the clients don't
     | need to.  The
     | expectation must be that many clients will query the RR,
     | having them all
     | do a bunch of extra work (like finding some postal code
     | to real location

Mr. Elz, where did you come up with the notion that some one has to do EXTRA
WORK or look up a postal code to figure out an address?

If the DNS is queried;
GL returns a physical location ie. '123 Anystreet, Anytown, Anystate USA
12345.6789' which is stored in the quoted string of GL. The postal code is
stored within the Hierarchical Locator which also contains the country code
and the Astronomical Location.  _For Those That Wish_ to use an external
database which makes use of such information.

_BUT_ there is absolutely no need to use one whatsoever.  The intention for
access to this type of information was to allow for tools to be built like a
geographic ping utility that display information on a map by using the RR.

_True_, a program that plots the information may need to do more work _BUT_
an individual person that does a query to the DNS has to do nothing to
figure out what the location is, it is visually superior to LOC (You must at
least concede this point). LOC will require a user to _ALWAYS_ convert the
LAT LONG & ALT to an understandable reference point. Unless you are a wiz
lat. and log. references.

     | database, and querying it) just to save the server (or
     | its maintainer)
     | from doing that once, is completely the anthesis of all
     | the DNS normally
     | sets out to achieve.
     |

As already stated, it (GL) save the maintainer work YES but does what LOC
does and NOT at the expense of anything. I am not sure what you are thinking
GL does but either I have explained something wrong or you are interpreting
something I have written incorrectly.

     | There are a also a lot of (comparativly minor) problems
     | with the draft as
     | it stands tat would need to be fixed were it to ever be
     | published as anything.

_PLEASE_ by all means tell me what is on your mind because I am
incorporating a series of 'improvements' and clarifications at this time
into a new version of the draft and I will continue to work on it.

     | But it isn't worth spending effort on getting those
     | fixed while the general
     | question remains as to whether there's any point in
     | defining this RR at all.

Well sir, in my mind, it is worth the effort, and I would truly appreciate
your and everyone else's help to make this RR the best it can be, within the
context of its definition.

I have said it over and over again, (IMHO) its simple to use/maintain and it
gives precise information.

Regards,

-al

---

From: Dan Schlitt <[email-masked]>
Date: Fri, 6 Aug 1999 09:49:26 -0400 (EDT)

ZIP codes????

How many zip codes are there in Cherry County Nebraska?? (If memory
serves, it is the largest county in the lower 48.) But then you might say
that cows don't have computers. That might have been true several years
ago. But today Ted Turner owns much of the county and I expect that he has
computers and the ranch probably has plenty of mobile computers. But not
many street addresses. On the other hand latitude and longitude will work
pretty well to locate things (if anyone really wants to know).

I used to enter LOC RRs in the DNS. But I stopped because it didn't seem
to be very useful. Using the DNS to locate things still doesn't seem very
useful to me no matter what RR one uses. If I want to find the location of
some object in space I would use a tool that goes directly to the NASA
database and not to the DNS.

/dan

-- 

Dan Schlitt                       System Management Arts	
[email-masked]                    14 Mamaroneck Avenue
tel: (914)948-6200 x 7210         White Plains, New York 10601

---

From: "Al Costanzo" <[email-masked]>
Date: Mon, 9 Aug 1999 10:27:45 -0500

I went throught great lenghts to explain how this is done.
Responding to the same question from another person.

If the message did not show up on this this list let me know.
I will resend it.

-al

     | -----Original Message-----
     | From: [email-masked]
     | [mailto:[email-masked]]On Behalf Of Dan Schlitt
     | Sent: Friday, August 06, 1999 8:49 AM
     | To: Al Costanzo
     | Cc: [email-masked]
     | Subject: RE: draft-costanzo-dns-gl-00.txt
     | 
     | 
     | ZIP codes????
     | 
     | How many zip codes are there in Cherry County Nebraska?? 
     | (If memory
     | serves, it is the largest county in the lower 48.) But 
     | then you might say
     | that cows don't have computers. That might have been 
     | true several years
     | ago. But today Ted Turner owns much of the county and I 
     | expect that he has
     | computers and the ranch probably has plenty of mobile 
     | computers. But not
     | many street addresses. On the other hand latitude and 
     | longitude will work
     | pretty well to locate things (if anyone really wants to know).
     | 
     | I used to enter LOC RRs in the DNS. But I stopped 
     | because it didn't seem
     | to be very useful. Using the DNS to locate things still 
     | doesn't seem very
     | useful to me no matter what RR one uses. If I want to 
     | find the location of
     | some object in space I would use a tool that goes 
     | directly to the NASA
     | database and not to the DNS.
     | 
     | /dan
     | 
     | -- 
     | 
     | Dan Schlitt                       System Management Arts	
     | [email-masked]                    14 Mamaroneck Avenue
     | tel: (914)948-6200 x 7210         White Plains, New York 10601
     | 
     |