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

From: "Al Costanzo" <[email-masked]>
Date: Wed, 28 Jul 1999 07:41:38 -0500

To the members of the DNS WG,

I have been working and continue to work on draft-costanzo-dns-gl-00.txt  I
would like to take a moment of your time to explain why I wrote the draft
and to ask the working group to review it.

The draft defines a new resource record for DNS which I have called GL
(Geographic Location).

Basically, the new RR allows a DNS administrator to place an entry into the
DNS defining the physical location of the machine.

The entry uses the postal coding system to define the location and also
allows the physical street address to be placed into the entry as well.

I became interested in creating this DNS RR after seeing a sample program
that use information (stored internally currently) which is able to do trace
routes, pings, etc. and display the information graphical on a world map.

The use of this RR would greatly improve a programs' ability that do this
sort of thing as well as help domain administrators to know where their
systems are. :-)

Before writing the draft, I looked at LOC (which from my research seems to
be a hold over from the wire days) and GLOC. (There may be more)   Neither
are widely accepted.  I define 'widely accepted' as more DNS entries using
it than not.

Using TXT records was not an acceptable solution since not only do I want
the location to be viewable, I want it to be in a specific, defined order.

I listen carefully to people who told me of:

--entries being removed if a new DNS administrator does not know what they
are/were.

--people not using the entry because they did not know how to properly
configure it.

--people not wanting to sit with a device and try to figure out the log. and
latitude of a location (especially when the administrator is responsible for
thousands of machines spread all over the world.

I therefore wanted a RR that would be:

1. Easy to configure (Everyone should know their postal mailing address :-)
2. Would be an understandable entry visually to a DNS administrator looking
at DNS entries
3. Achieve the desired result (store the physical location)
4. Because of its ease of configuration would become 'widely accepted'
5. Most countries have postal codes and the ID has allowances for those that
do not.

But to accomplish #4. I need this WG to endorse the concept so that this
draft could be considered for standards track.  It will never be widely used
otherwise.

If you have time therefore please take a look at the draft and let me know
your opinions.

I have already incorporated 99% of the ideas this list has sent to me in
June into this draft (including how to map to location not on planet Earth).
I am sorry I could not complete the first rough draft before the last IETF
meeting.

The draft is located at:

http://www.ietf.org/internet-drafts/draft-costanzo-dns-gl-00.txt

The draft does not contain all of the references used and may have a typo or
two but I would appreciate comments and feedback.

Regards,

-al

---

From: Robert Elz <[email-masked]>
Date: Thu, 29 Jul 1999 10:57:05 +0700

Date:        Wed, 28 Jul 1999 07:41:38 -0500
    From:        "Al Costanzo" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Before writing the draft, I looked at LOC (which from my research seems to
  | be a hold over from the wire days) and GLOC. (There may be more)   Neither
  | are widely accepted.  I define 'widely accepted' as more DNS entries using
  | it than not.

I'm not sure how to interpret this.  If you mean (which is what it looks
like) "more domains using it than not" (ie: more names in the DNS have the
RR type attached than do not) then I am pretty sure that by your definition
no RR type is widely used (not A, not MX, none at all).

If you mean that more zones include at least one RR of the type, then
certainly SOA and NS would qualify, but I am not sure that anything
else necessarily would.   A just might get in, but not by a large margin.

I suspect that you just mean "there aren't as many of them as I think
there should be", which turns out to be fairly meaningless.

  | --entries being removed if a new DNS administrator does not know what they
  | are/were.

Perhaps some of that - probably more "does not know what they are
useful for", which I suspect would apply just as much to your record.

The way to get a new RR type widely deployed is to make, and distribute,
a great application which depends upon it.   Then people will add the
RR type that is needed.   You can't hope to get any RR deployed with the
expectation that its existence will inspire the application you would like
to see exist.

If you could get the graphical traceroute tool using LOC records and
made widely available and used, the use of LOC records would most likely
increase dramatically (you'd still have the people who don't want anyone
to know where their systems are, but no record of this type is going to
affect them).

  | --people not wanting to sit with a device and try to figure out the log. and
  | latitude of a location (especially when the administrator is responsible for
  | thousands of machines spread all over the world.

Remember this for later...

  | I therefore wanted a RR that would be:
  | 
  | 1. Easy to configure (Everyone should know their postal mailing address :-)
  | 2. Would be an understandable entry visually to a DNS administrator looking
  | at DNS entries
  | 3. Achieve the desired result (store the physical location)
  | 4. Because of its ease of configuration would become 'widely accepted'
  | 5. Most countries have postal codes and the ID has allowances for those that
  | do not.

#1 & #3 seem contradictory to me - especially given your point above.
If I, as the administrator of thousands of machines around the world am
sticking my postal address in some RR for all those machines, it is going
to be my postal address, which would have little to do with the physical
location of almost any of the systems.

What's more, even if I have just one host, its postal address is only
very loosely related to its physical address - they're probably in the
same city, but that's about the end of the relationship.

On #4 - ease of configuration will do nothing to make it widely accepted.
There needs to be a demand to achieve that.   Nothing this WG can do will
help either (though it may be possible to hinder things).

kre

---

From: "Al Costanzo" <[email-masked]>
Date: Thu, 29 Jul 1999 10:02:09 -0500

>Robert Elz wrote:

     | Before writing the draft, I looked at LOC (which from my research
seems to
     | be a hold over from the wire days) and GPOS. (There may be more)
Neither
     | are widely accepted.  I define 'widely accepted' as more DNS entries
using
     | it than not.

    >there should be", which turns out to be fairly meaningless.

To further qualify my statement:  I consider 'widely accepted' to mean that
more people use the DNS entry to define a machine in an entry that is
defining a machine.  ie. If the machine has a A entry you would think
(unless as you say, the administrator does not want you to know where the
machine is) would have a physical location entry.

I just do not see many entries, but I will concede that I did not do a
through, exhaustive search all over the world.

    | --entries being removed if a new DNS administrator does not know what
they
    | are/were.

    >useful for", which I suspect would apply just as much to your record.

I tend not to agree with you here.  IF you look at a GPOS entry in the DNS
for example, I would think the entry was entirely bogus, I never saw
anything like it, its just three groups of positive and/or negative numbers.

Looking at it visually, esp. with no comment, I have no clue what it does.
Please realize that neither of the two entries have comments below. The
quoted string is part of the GL entry.

Compare:

          GPOS    -32.6882 116.8652 10.0

(to)

donuts A 192.188.192.1
         GL S3.US.45420.1910 "1425 Arbor Avenue, Dayton OH"

The record I am defining would at least let someone immediately understand
that what is being defined 'looks like' a physical address.

To me at least, this looks like an address.

   >a great application which depends upon it.

I agree!!

   >Then people will add the

The application already exists!  NeoTrace for one.

   >to know where their systems are, but no record of this type is going to

As I say, an application already exists, however, since so few people use
the LOC RR that this is really a mute point.

  | --people not wanting to sit with a device and try to figure out the log.
and
  | latitude of a location (especially when the administrator is responsible
for
  | thousands of machines spread all over the world.

  >Remember this for later...

I am still 'remembering this for later' but I do not see a comment regarding
it.

  | I therefore wanted a RR that would be:
  |
  | 1. Easy to configure (Everyone should know their postal mailing address
:-)
  | 2. Would be an understandable entry visually to a DNS administrator
looking
  | at DNS entries
  | 3. Achieve the desired result (store the physical location)
  | 4. Because of its ease of configuration would become 'widely accepted'
  | 5. Most countries have postal codes and the ID has allowances for those
that
  | do not.

  >#1 & #3 seem contradictory to me - especially given your point above.

Not at ALL...

  >location of almost any of the systems.

A little miscommunication here (my fault), I would not enter 'my' postal
mailing address the same as I would not enter the same A address for each
machine.

The administrator would enter the physical (postal) address of the machine's
location.

  >same city, but that's about the end of the relationship.

In the example I show in the draft (and above) the machine being defined is
in Dayton Ohio and the GL RR uses that address, my physical address has
nothing to do with this RR. (I'm in New Jersey!) It is the physical address
of the machine that is to be used.

  >help either (though it may be possible to hinder things).

The working group can not force it to become widely accepted _BUT_ it sure
is able to help begin the process.

No one will write application(s); good applications around something defined
in an experimental RFC.

I remember how everyone came down on Microsoft for doing just that. (A few
years ago; I was at the IETF meeting in Amsterdam)

I do not mind doing work, and I'm more than willing to make (or have made)
programs that use the GL RR and distribute if for free for testbed purposes.

But all my work will be for nothing, I believe, if the document is not on
standards track, if it just sits on experimental status, IMHO it will just
flounder and never be noticed.  I do not think anyone wants to do work and
then have that work be useless or become a futile project. (I sure do not!)

IMHO GPOS and LOC will never be widely used, I think what I am defining here
may be. I asked people that would be in a position to use the RR and tried
to get as much input as possible from this list and other sources.

I therefore conclude that this WG is in an excellent position to assist in
getting the RR wide accepted, by 1) reviewing it making suggestions and 2)
approving the document for standards track.

In my opinion, this RR is the best way to specify a geographic location of a
machine in DNS and as others have already mentioned, neither LOC or GPOS are
able to do what the GL RR can.

Thank You for your comment(s)...

Regards,

-al

---

From: Jerry Scharf <[email-masked]>
Date: Thu, 29 Jul 1999 17:10:20 -0700 (PDT)

Since I did some bashing last time around, I tried to stay silent, but I
can't do it any longer. You are saying you want this as a standards track
RFC so that it can be used in a widespread way. Then you use the example
of non PS records to say they have not become sufficiently widespread, and
you need something new. Then you say you have a proposal that does
something that is much better, but you choose as your "killer app"
something that can already be done with LOC records. The crux of your
argument is that you don't like how LOC looks, not what it does for your
application.

Others can disagree with you, and I have. When you come up with the
situation that people are yelling for and can convince a set of skeptics
that your RR is an excellent solution for it, then you have something. So
far I have not seen anything like this. The fact that no one has modified
traceroute to use LOC records is a fairly good indicator of how pressing
the need for your

SRV records started as experimental, and is moving to PS with significant
application push behind them. SRV is now called out in the ITU H.323 specs
and is about to get wide use in Windows 2k, and we have learned enough
about it to put in on standards track. If you are saying that your RR
should be PS, I think not.

This brings up the interesting question of what happened to the
kitchen-sink RR discussion in Oslo. I don' remember seeing it in the
minutes and this would be a prime candidate for that RR. It might also
give nameserver implementors a way out of the current effort of
implementing RRs and make this kind of discussion unnecessary. 

jerry

---

From: "Al Costanzo" <[email-masked]>
Date: Thu, 29 Jul 1999 23:51:53 -0500

Jerry Scharf wrote:

   >RFC so that it can be used in a widespread way.

What I'm saying is that experimental RFCs tend to go nowhere. point blank.
And I want the
WG to review the document and make suggestions to improve it so that it
could be the best it can be.  I hate shoddy workmanship.  _AND_ yes I want
the final document to be considered for standards track.

  >Then you use the example
  >you need something new.

Please keep things in context.  The example was to illustrate the
'readability of
a GL record vs. what I consider an ugly looking GPOS record. Nothing more.

  >Then you say you have a proposal that does
  >something that can already be done with LOC records.

You are referring to what others have said on this list, I only repeated.

I believe the reference was to be able to define a location anywhere in the
known Universe.

I never said you could not do it with LOC, GPOS or TXT records for that
matter. I _AM_ saying that I believe GL is a better way to do the definition
of a Geographic Location of a machine defined in the DNS than any of the
other methods.

  >The crux of your

No. My point is that, and I will state it again. I do not feel that LOC is
widely accepted/used and I feel that users will warm up to a RR that is more
'user' friendly looking.

_And_ I think an application will be able to do much more with GL than LOC.
Did you read the draft? The Locator does wonders.

   >Others can disagree with you, and I have.

Your the only one I have counted so far. Others have had constructive
criticism or misunderstandings in the definition and at least two approve
(I'm counting :-)

   >When you come up with the
   >the need...

Maybe no one modified traceroute because NO ONE puts the record into the DNS
in the first place, just like I have been saying. Why should vendors waste
time if no one uses an old RR that was defined way back in the 'wire' days.

IMHO the problem is with the RR definition (LOC, GPOS as well) the way they
look and what they do.

   >...for your SRV records started as experimental, ...

Been there, done that, and will _NEVER_ do it again. First, get the WG to
consider a thing to be put on standards track then put out great
applications that make use of it.

Expended much resource and time on work just to have a few loud mouths at an
IETF meeting kill an idea and watch all the work go up in smoke.  Not this
time, I'm presenting the idea to the WG first.

  >and is moving to PS with significant

You do a lot of mumbling and grumbling, please tell me why not. Explain
yourself. Nothing you have said in this email states any valid reason why
not.

Bash all you want, but if your going to bash, convince me that you are right
and I am wrong just don't say '... your doing this cause you do not like the
way LOC looks."

Your right! I don't and many others don't either and I think that is ONE of
the reasons it may not be used to much.  GL is a solution.

_AND_ if as you say this is not an earth shattering issue why are you so
opposed for it to go onto standards track?

Is the draft without technical merit, i.e. you think it will not work? It
does.

   >implementing RRs and make this kind of discussion unnecessary.

I can see I just don't agree with any of your mindset, sorry.

The kitchen sink RR? I strongly disagree.  Geographic Location has been/
being tossed around for a while in one form or another and it should have a
RR all its own.

Only my opinion.

-al

---

From: "Al Costanzo" <[email-masked]>
Date: Thu, 29 Jul 1999 23:51:53 -0500

Only my opinion.

-al

---

From: Dennis Glatting <[email-masked]>
Date: Thu, 29 Jul 99 23:42:04 -0700

> Your the only one I have counted so far. Others have had
> constructive criticism or misunderstandings in the
> definition and at least two approve (I'm counting :-)
>

I think the Security Considerations section of RFC-1876
speaks for itself and LOC/GL/whatever not be given serious
consideration. The usefulness of LOC and GL is a matter of
people using it. I, for one, consider it no one's business where
my resources are physically located.

-dpg

---

From: Terry Lambert <[email-masked]>
Date: Fri, 30 Jul 1999 11:31:45 -0700

> my resources are physically located.

Add me to the list of people who disagree.

Not to mention that people could easily target you for
direct mail marketing, based on a correlation between an
email address disclosing your name and posting host, and
a DNS lookup of the street address of your posting host.

It seems to me that this would be an "ideal" way to get
a list of "qualified" business "leads" for a snail-mail
marketing campaign.

I, too, am not going to be putting street address information
in my DNS.  Electronic SPAM from the harvesting of this
mailing list is bad enough (though on the plus side for
the electronic stuff, at least I get to bill for that).

Painting missle coordinates on .MIL hosts via LOC records
was a silly idea, too, for that matter.

-- 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: "Al Costanzo" <[email-masked]>
Date: Sat, 31 Jul 1999 12:32:27 -0500

Terry & others,

   My proposal is not to force an entry into anyones DNS to specify the
location of your machines just like no one forces you to use CNAME or HINFO.

   It is to allow those who want to keep track of the physical locations of
their machines a method to do it other than using TXT or some other
record(s) that do not do it as well.

-al

-----Original Message-----
From: Terry Lambert [mailto:[email-masked]]
Sent: Friday, July 30, 1999 1:32 PM
To: [email-masked]
Cc: [email-masked]; 'Jerry Scharf'; [email-masked]
Subject: Re: draft-costanzo-dns-gl-00.txt

-- Terry Lambert