Subject: Re: draft-costanzo-dns-gl-02.txt

From: Jerry Scharf <[email-masked]>
Date: Thu, 01 Jun 2000 11:46:56 -0700

Folks,

here we are recycling the same discussion that happened on this a year ago. We 
once again have the same arguements:
	This record has an information collection that no other record has
	There are other records that have parts of the information
	All this information could be represented in other records
	The real world deployment schedule for this is 3-10+ years
		(resolvers and nameservers needs to be revved)
	The ability of people to maintain this is suspect

Now the meta issue. I think most all of the old-timers see DNS as very 
different than MIME, where anything goes and there is little cost to adding 
new types. It is clear that some people do not see it this way and want their 
data forms in new RR types. Unless we agree to a specific direction out of 
this area, this discussion will happen repeatedly from now on. I thought that 
KS was supposed to get us out of this mess, but in the discussion last time 
almost everyone agreed that KS was not the solution. So we need to find some 
other way out of this swamp, or allow the swamp to continue to grow.

Since LDAP is designed specifically around extensable schemas, maybe the right 
answer is to come up with an LDAP referral RR that contains a server and a 
base query string. Then all these functions become a standardized form of 
asking LDAP queries with a standardized form of extending the base query 
string.

This may not be a work of art, but at least it gives a clear direction for 
people who want to add extensible information about hosts to go.

jerry

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Terry Lambert <[email-masked]>
Date: Thu, 01 Jun 2000 15:35:00 -0700

Let me first say that I won't personally configure geographic
information, and so long as there are ISPs that have multiple
POPs in potentially multiple geographic localities, I don't
think you will be able to get accurate information for anything
but things with static IP addresses anyway, and sometimes not
even then.

Jerry Scharf wrote:
...
> Since LDAP is designed specifically around extensable schemas,
> maybe the right answer is to come up with an LDAP referral RR
> that contains a server and a base query string. Then all these
> functions become a standardized form of asking LDAP queries
> with a standardized form of extending the base query
> string.
> 
> This may not be a work of art, but at least it gives a clear
> direction for people who want to add extensible information
> about hosts to go.

I think this misses the implied point, which is what no one
seems to be willing to do other than skirt around:

It is not for you to want or to not want to provide this
information; in theory, your ISP will provide it.

People want to know the geographic location of a machine so
that when someone comes in to their web site from a machine,
they can gauge the locality of the advertising that caused
the customer contact to take place, even if the customer
chooses to not buy anything or procide other information.

Someone who wants to bury you in targetted advertising can't
tell on which radio station you heard their advertisement
without some geographic clue.

Likewise, they can not judge the effectiveness of the junk
mail they sent to a given geographic region without some way
of correlating the locality of the responding machine with
the set of localities to which they sent the junk mail.

Imagine radio or print ads that are paid for based not on
size of market or times run, but on "click through".

Sort of "Nielson ratings" with involuntary participation.

Or imagine someone accumulating a database of a geographic
locality vs. machine.  Do you really want your local grocer
sending you targetted SPAM because you happen to be in the
neighborhood?

Can someone give a _legitimate_ reason for wanting geographic
information about machines?

Example: Are we finally going to design a transport protocol
where you ask a service (a _service_, not a _server_) for
data, and we don't care where the answer comes from, so long
as it comes from some acceptable source, and comes before we
need it to have arrived?  Is it necessary to the design to
have the physical location of the servers to do this?

The only use I can think of is marginal cost reduction on
targetted marketing... hardly a reason to do it, and mostly
a reason to _not_ do it.

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [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: Mike Davison <[email-masked]>
Date: Thu, 01 Jun 2000 22:38:29 -0700

> information about machines?

I'm not claiming that DNS is the best method, but there is at least
one good reason for wanting the geographic location of a client machine.
Language. It is nice if content providers can provide their content in 
German, French, English, etc. as appropriate. 

Some content providers already do this based on other factors with about 
70% accuracy. The proposal outlined in draft-costanzo-dns-gl-02.txt 
probably wouldn't do any better than 70%, but that does not mean that
DNS-based approaches could not address this issue. Nor does it mean
that there is no valid reason to learn the geographic location of the 
client.

Of course, it might actually be more useful to have a 'services 
preferences' DNS record rather than a geographic location. This record
could indicate what sort of localization the client wishes. But again,
DNS may not be the right tool.

> have the physical location of the servers to do this?

HTTP redirect is a reasonable, although clunky, example of this. 
Client connects to www.content-r-us.com. Server makes guess about
location of client based on client's address and routing data. 
Server redirects the client to a localized/closer/less-loaded/etc server. 

Mike

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 02 Jun 2000 09:29:20 +0200

>asking LDAP queries with a standardized form of extending the base query
Given that LDAP has gone down every single one of the ratholes dealing with 
names and addresses already, and is far more geared towards creating more 
ratholes without taking down the system, AND has a defined URL format, I 
think that creating a "see-also" record that can contain an URI is a 
sensible way to go.

It doesn't even have to be an LDAP uri.
"microsoft.com SEE www.microsoft.com" might make sense (to Microsoft), 
while "mymachine.alvestrand.no SEE 
ldap://ldap.alvestrand.no/CN=mymachine,O=alvestrand,C=no??" might make 
sense for one of my computers (if I could be bothered to register info on 
them).

Wasn't something like this a proposal some time back?

                         Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Jerry Scharf <[email-masked]>
Date: Fri, 02 Jun 2000 00:57:29 -0700

It might make sense to have an RR that has a URL and a service name. That way 
I can have a few different URLs at the same point. My idea would be that 
service names are opaque to DNS, unconstrained and not IANA allocated. You 
would certainly need to allow a "*" service, and you could even think of 
allowing a regexp to be interpreted by the application. When you ask for the 
type, you get the entire RRset just like everything else.

If someone wants to manage service names in some way, I would see that as 
beyond the scope of the WG.

jerry

---

From: "M. T. Hollinger" <[email-masked]>
Date: Fri, 2 Jun 2000 07:33:55 -0400

> German, French, English, etc. as appropriate.

Sure, that's an example.  Within a country, this information could also be
used as a default to display weather forecasts, sports scores, local news,
TV schedules, telephone listings, or links to local chapter information
relating to the organization running the website.  Of course, the user
should be able to access other geographic areas (like Yahoo's "change
location" link), but getting a default that's appropriate even 50% of the
time would be a real convenience for users.  This stuff all came up last
year, when we previously discussed location RR proposals.

However, the most popular use for this information, I think -- and the
reason to consider providing it in the DNS, rather than in an HTTP-specific
way -- is simply to allow server operators (FTP server, web server, chat
server, or the-next-big-thing server) to keep statistics.

At IETF plenary meetings, we often see a list of how many attendees are
there from each country.  Why?  Can anyone give a _legitimate_ reason for
wanting to know how many people from Sweden attended the Danvers IETF?  (If
not, would that mean the information shouldn't be collected or shared?)

When travelling on vacation, I often pass the time by looking at people's
bumper stickers or baseball caps just to see where they're from.  In
Vermont, during ski season, it sometimes seems like 20% of the license
plates are from New York, and 25% from Massachusetts.  Now, privacy
advocates may point out that I have no right to know where that stranger in
front of me is from.  Those who insist on complete accuracy may complain
that the parked car I just saw with Connecticut plates may actually be
rented by a German family.

While driving a rented car at the Munich IETF, one of the locals warned me
that people there might see its Frankfurt plates, incorrectly conclude that
I was from Frankfurt, and be more likely to cut me off, as residents of
those regions have something of a rivalry.  Similarly, while travelling in
Canada, I may make a long-distance dial-up connection to my home server in
the US and be incorrectly counted as a US visitor when I access the website
of the local science museum to find their hours of operation.

Still, imperfect as the information is, it's interesting to see where your
visitors are from.  A Save the Whales website operator may wonder how many
people from Norway are reading his homepage.  Somebody running an FTP
archive of Beatles lyrics might find it interesting if most of his users are
from China and Taiwan.  Perhaps he can, over time, tailor the content of his
archive to those users.  But even if he takes no action, he might just like
to know, because it's interesting information.

The Internet is all about collecting, organizing, and sharing knowledge.  In
general, I think that's good.  Privacy concerns dictate certain limits or
controls on the automated sharing of personal information (such as your name
and street address), but for demographic information (such as what country,
province, prefecture, or state you may be from), I don't see much of a
threat.  If some people want to know, and other people want to tell them,
our role as Internet engineers is to provide a mechanism to facilitate that
communication.

          - Mark

---

From: Jerry Scharf <[email-masked]>
Date: Thu, 01 Jun 2000 23:53:25 -0700

Terry,

I don't disagre in any way with anythign you say. My point was that much of 
this discussion happened when GL was first discussed about how useful the data 
really is. I think you define a specific use model, then reason why it doesn't 
work. All it takes is for them to say that's not how they were going to use 
it, and the discussion continues on and on...

My point is that I don't really want to have to poke holes in each new RR type 
request that wants to put some other type of information in DNS that is of 
questionable value for the desired use and has standardization and 
implementation effort involved. I want some place to send them to that they 
can feel happy enough with that it won't show up on namedroppers. Until we 
have some other thing to point to that lets people do this, each one will end 
up on our doorstep. As this rehash proves, they don't go away easily.

Officially saying "use LDAP (or whatever) and here's how" and "we hereby 
consider adding RR types in lieu of this to be an extrordinary action" will 
give us a real way to tell people to go away.

jerry

---

From: Dennis Glatting <[email-masked]>
Date: Fri, 02 Jun 2000 06:24:50 -0700

> German, French, English, etc. as appropriate.

Language is not a geographical issue. It is a personal choice.

---

From: "Al Costanzo" <[email-masked]>
Date: Fri, 2 Jun 2000 09:17:58 -0400

> information about machines?

Example:

Yes I can....  We are a National ISP... We are multihomed we want to keep
track of where each router/node/machine is, since we have to configure DNS
anyway, create a 'simple' RR that allows the information to be entered.

Why maintain an offline database for this information? We think it is a part
of DNS and we do not consider it 'bloat' nor a 'kitchen sink' type record..
This is important information that should be available...

Most people do not have GPS'es

End example///

I have already have been told the reasons why people do not use LOC records.
This draft was written to make it as simple as possible with the 'best
possibility' of getting accurate information and having the RR actually
used.

One DNS mplemetor has contacted us already about the draft and another
comany likes the record for doing a 'geographical' traceroutes since most
domains do not contain LOC records.

It is much easier for implemetors to query DNS that has a structured record
to get the information they need then to go crazy trying to figure out how
to parse a free formed TXT record....

Writing this draft has shown me that implemetors really do read IDs and
there seems to be interest in this RR in the industry.

Another programmer wants to submit it to Linux so I think once that happens
this RR which is still only an ID mind you, will be supported on, (Windows
95,NT,2000 & now Linux)

Regards,

-Al

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 02 Jun 2000 10:29:38 -0500

> German, French, English, etc. as appropriate.

We have plenty of single hosts here with multiple users logged in
whose Accept-Language: sets have little overlap.

By the way, we already have Accept-Language for this function, don't we?

				Matt
Accept-Language: en,es,pt,fr,de,ru

---

From: Terry Lambert <[email-masked]>
Date: Fri, 02 Jun 2000 14:29:38 -0700

M. T. Hollinger wrote:
> >Terry lambert wrote:

[ ... Jerry's example ... ]

> Sure, that's an example.

[ ... default locale specific content ... ]
[ ... locale based statistics keeping ... ]

This use will simply not work, unless the draft mandates
that the information either be correct or omitted.  When
omitted it will not work for the majority of cases.  It
simply can't work for dynamic IP address assignment unless
the draft mandates a TTL of 0, and further mandates that
all DNS servers honor this as a request not to cache, and
that all DNS servers that have minimum TTL values that
they substitute for cached entries (e.g. 300) discontinue
this practice.

This is because the DNS records are owned by ISPs, and the
forward lookup of the reverse record will not give accurate
GL information, without great effort and no caching.

I have an ISP account with UUNET.  I am dialed into a POP
which is not my home POP.  Where am I located?

The argument that these records apply to anything other
than static IP addresses, meaning machines with fixed
locations, is ludicrous.

> At IETF plenary meetings, we often see a list of how many
> attendees are there from each country.  Why?  Can anyone
> give a _legitimate_ reason for wanting to know how many
> people from Sweden attended the Danvers IETF?  (If not,
> would that mean the information shouldn't be collected or
> shared?)

I can: in order to reassure citizens of each locale that
their locale did, indeed, have representation on committees
which ratified standards.  This lends an air of perceived
legitimacy-through-egalitarianism to IETF standards.  In the
technical limit, there is no additional legitimacy granted
by this, but it lets non-technical people feel warm and fuzzy.

Note that you are free to choose "other", if you feel your
privacy is being violated by this practice.

> If some people want to know, and other people want to tell
> them, our role as Internet engineers is to provide a mechanism
> to facilitate that communication.

We have one: your web site _asks_ via a form, and your user
_tells_ via a POST.

GL suggests that when some people want to know, their ISP tells
them, regardless of what other people want or do not want.

-- Terry Lambert

---

From: Terry Lambert <[email-masked]>
Date: Fri, 02 Jun 2000 14:45:07 -0700

Jerry Scharf wrote:
[ ... ]

> Officially saying "use LDAP (or whatever) and here's how"
> and "we hereby consider adding RR types in lieu of this
> to be an extrordinary action" will give us a real way to
> tell people to go away.

This is perhaps workable, so long as we don't make it the
job of the LDAP people to point back at the DNS people to
brush off people that the DNS people have already brushed
off once.  We do not need a finger-pointing war.

To Harald's elaboration on this suggestion: we already have
the LDAP capability with SRV records, and there are
algorithms (admittedly they are different from LDAPv2 and
LDAPv3) for getting the base DN, so I guess the problem is
already solved.  Right?

So we can state:

	That is not the type of information that belongs
	in the DNS.

Then it's up to the people who want this information to:

1)	Get an RFC for LDAP use of SRV records approved,
	since SRV records object to being used without
	an RFC per protocol on how-to-use.

2)	Define schema to use for this, and convince
	everyone to use it and fill it out correctly for
	transiently connected machines on dynamically
	assigned IPs, just as they would have to convince
	people to do to deploy GLs and set TTL=0.

Can we all live with that as an answer?

Then the next time someone wants a new RR type for some
other specific and not obviously useful addition, we can
point them at that method, instead?

This would certainly work to obviate the need for the GL
draft going forward, and we could dismiss the idea now.

-- Terry Lambert

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 02 Jun 2000 21:41:08 -0400

Terry Lambert wrote:

> point them at [a SRV+LDAP] method, instead?

An exception should probably be made for so-called DNS "metadata", since
it makes little sense to store that in a separate database.

- Kevin

---

From: Jerry Scharf <[email-masked]>
Date: Fri, 02 Jun 2000 23:41:50 -0700

> LDAPv3) for getting the base DN, so I guess the problem is

Being an ignorant slob about the LDAP mapping capability, I would like to hear 
from people who have the ideas of doing things like GL and see how this could 
work for them. Certainly the more general URL case the Harald proposed should 
be able to work.

> 	an RFC per protocol on how-to-use.

Given the recent messages that this is already in use, it seems like a good 
idea no matter what.

> 	people to do to deploy GLs and set TTL=0.

I think there is also the sticky widget of where this data is attached in the 
hierarchy below the DN mapping you mentioned above. I have this idea that the 
goal is to get back just the GL (or other) schema, and so it needs to be a 
more specific query than just the DN. Passing the query punts this problem.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 03 Jun 2000 11:16:49 +0200

>LDAPv3) for getting the base DN, so I guess the problem is

not quite - I think SRV records for LDAP were intended to indicate "here is 
the address of the LDAP server to contact about information belonging to 
the hierarchy owned by the controller of this name".

A SEE URL record would indicate "here is more information about the single 
named entity that this name belongs to".

Note also that a SRV record can't provide the non-machine part of the URL 
(a search criteria, distinguished name or other info).

              Harald

---

From: Terry Lambert <[email-masked]>
Date: Mon, 05 Jun 2000 13:35:53 -0700

Harald Tveit Alvestrand wrote:
> not quite - I think SRV records for LDAP were intended
> to indicate "here is the address of the LDAP server to
> contact about information belonging to the hierarchy
> owned by the controller of this name".
> 
> A SEE URL record would indicate "here is more information
> about the single named entity that this name belongs to".
> 
> Note also that a SRV record can't provide the non-machine
> part of the URL (a search criteria, distinguished name or
> other info).

Actually, it can provide whatever the draft authors wish
it to provide, but you're right, it currently doesn't
provide for as much as a full LDAP URL would.  The current
draft is:

http://www.ietf.org/internet-drafts/draft-ietf-ldapext-locate-02.txt

It does, however, provide enough to do the same job that GL
is supposed to be intended to do.

It would be pretty easy to define a GL schema; the RDN off
the base DN could contain the actual machine name, so one
directory could contain all of the information about all
the machines in a domain, e.g.:

	objectclass GLResourceRecord
		requires
			objectClass,
			cn,
			GLAstronomicalLocation,
			GLCountryCode,
			GLPostalAddress
		allows
			GLPostalZone

And the "donuts" example:

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

Becomes this LDIF:

	dn: cn=donuts.example.com,dc=example,dc=com
	cn=donuts.example.com
	objectclass: top
	objectclass: GLResourceRecord
	GLAstronomicalLocation: S3
	GLCountryCode: US
	GLPostalZone: 45420.1910
	GLPostalAddress: 1425 Arbor Avenue, Dayton OH

I locate the LDAP server for the site via:

	_ldap._tcp.example.com. IN  SRV  0 0 389 boo.example.com.

bind to the server, discover the base DN, and then within
the base DN, perform the search for "donuts.example.com":

	(cn=donuts.example.com)

which will return the appropriate GLResourceRecord object.

I think the point that LDAP is a hierarchical data store,
just as DNS is a hierarchical data store, and that LDAP,
unlike DNS, is arbitrarily extensible, is the salient one.

Plus it's appropriate to use a directory server to contain
address information.

I still dislike the idea that my ISP will be ratting me
out about my physical location, but I suppose they could
put in TXT records to do the same job today.  A topic for
"Risks", not this list, I suppose...

-- Terry Lambert

---

From: Jerry Scharf <[email-masked]>
Date: Tue, 06 Jun 2000 10:18:31 -0700

I also prefer the SEE rrtype, but want to add a tag as well as a URL.

The problem with a bare URL is it's difficult to know if what you are getting 
is a GL record or a yahoo map link. Remembering that DNS is for programs and 
not users, being able to know what is would come back is an important feature. 
Adding a tag allows a program to quickly tell whether attempting a TCP 
connection to the URL is merited. There are certainly details of such a tag to 
thrash through, but being able to have a LDAP-GL tag on a RR gives the 
applicaiton a good hint of what to expect. More to the point, if I'm after GL 
data, I know not to follow RRs that don't have LDAP-GL tag.

I would specifically argue against IANA management of the tag namespace, but 
that's part of thrashing it out.

jerry

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 06 Jun 2000 10:06:11 -0700

> the machines in a domain, e.g.:

Given that not all external references need to point to LDAP, nor is it
desirable to mandate that all external references point to LDAP, I think
that having a generic URL as the SEE record's data is probably the best
way to go. You could just have a SEE record that pointed to a company's
driving directions page with a map on it, or you could point to the
full-glory LDAP data if you want to, meaning that a generic URL allows
for either a simple answer or a complex answer, but doesn't require a
complex answer when a simple answer is all that's desired.

For non-location data, there is probably a use for a generic see-also
record that is associated with common aliases. Maybe you have an ftp
CNAME record, and putting a SEE ftp://ftp.domain.dom is an obvious thing
to do there. Less obvious could be home pages for sub-domains with the
SEE record returned along with the other domain records, or gopher://
menus for departments, or anything else you care to do.

Essentially, making the referral as dumb as possible seems like the most
economical thing to do from DNS' perspective, and also provides the most
flexibility for the administrator without also requiring that the client
have access to an LDAP agent. Dumber is probably better for a generic
referral mechanism.

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com

---

From: Terry Lambert <[email-masked]>
Date: Tue, 06 Jun 2000 10:29:16 -0700

Eric A. Hall wrote:
> Essentially, making the referral as dumb as possible seems
> like the most economical thing to do from DNS' perspective,
> and also provides the most flexibility for the administrator
> without also requiring that the client have access to an
> LDAP agent. Dumber is probably better for a generic referral
> mechanism.

Now I have to defend GL records... 8-(.

The point of introducing GL records to the DNS was, I
think, to ensure that there was "One True Way" to get
geographic location information about machines.

Imagine if we were to try to publish DNS data over
gopher:// URLs instead of a well known port with a
specific protocol.  It _could_ be made to work, but
why bother, when it won't be commonly implemented due
to it's lack of being a "One True Way"?

If we can't meet this "One True Way" requirement without
adding GL, then it defeats the purpose of even pretending
to do the job some other way.

A generic referral is perhaps useful, but it is also
something that more properly belongs in KS, and thus
has seriously limited utility, as anything one could
imagine placing in KS would similarly not act as a
useful Schelling point for a data provider and a data
consumer to perform a protocol rendesvous.

I don't think that I can overemphasize the need for a
single, universally recognized rendevous for GL data
as a requirement for the problem GL is trying to solve.

Whether it's actually useful to solve this problem at
all is a seperate question.

If we accept for the sake of argument that the problem
is worthy of soloution, then we have to meet the "One
True Way" requirement, one way or another.  GL is one
way; specifying a directory rendevous is another, and
there are uncountable other possibilities, but it's
only useful if a single one is picked and deployed.

-- Terry Lambert

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 06 Jun 2000 13:54:21 -0700

> consumer to perform a protocol rendesvous.

My belief is that DNS is not viable as a generic directory service. The
lack of authenticated vs anonymous queries alone precludes this usage.
The lack of a version field in conjunction with the lack of in-stream
definable datatypes and schema precludes it from ever becoming one, even
if anonymous access is all that's ever desired (which it isn't, people
want different answers depending upon who's asking each of the specific
questions).

The merit of a see-also rr is that it allows for rerrals to external
data such as GL, not that it would make GL data in particular easier to
grok. Defining explicit extensions to see-also which indicate the type
of data being referenced is just as much effort as defining the GL RR
and every other attribute/schema explicitly. That puts us back into the
DNS-as-directory argument.

This doesn't even address the issue of how you would make GL data
meaningful beyond what is already provided with LOC. The *ONLY* way you
will ever have assured access to valid location data is if you can find
a way for every postal system in use today to be consolidated, and to
get every governmental jurisdiction to mandate its use (and moreover,
that they mandate it be used with accurate, globally-meaningful data).
My guess is that the best resolution you will ever get is what you have
now: lat/long provided on a volunteer basis.

> as a requirement for the problem GL is trying to solve.

Personally, I'd suggest that adding a content-GL header to HTTP would
probably be the best solution to the examples given. If a user wants to
provide their location data on a per-transaction basis they can, and
HTTP proxies can overwrite the data if the user is (im)mobile. The GL
data can point to LDAP objects if large amounts of detail (or LDAP
storage) are desired.

---

From: Jerry Scharf <[email-masked]>
Date: Tue, 06 Jun 2000 14:23:59 -0700

(some of my mail to namedroppers seems to be vanishing. If you saw some of 
this before, I'm resending this becuase I didn't see the list echo.)

Terry,

I think there's a middle ground between One True Way and no idea at all. I  
think that there be some flavor of tag for seeing if the URL is related to GL 
or not. The first thing that came to mind was something like LDAP-GL, but it's 
an arbitrary string. To my mind, it's also not managed by the IANA except for 
some predefined prefixes like LDAP- ... The tage can always be null.

My reason for it is that it is mighty expensive to sort through n URLs that 
have nothing to do with the data you are looking for. DNS is for programs, not 
for users. This means that the idea of put anything you want behind the URL 
makes it a mess for programs. This way a program can look through the RRs in 
the RRset and see if any have the tag that they know what to do with, and only 
get those. If I were writing a program, I would simply toss any URLs that I 
didn't recognize the tag for. Now someone could still put the wrong tag on 
something and I would get trash, but that's still better than without the tag,

jerry

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 06 Jun 2000 23:42:50 +0200

At 14:23 06.06.2000 -0700, Jerry Scharf wrote:
>something and I would get trash, but that's still better than without the tag

the approach of a text tag has been used with some success in LDAP.
See this RFC:

2079 Definition of an X.500 Attribute Type and an Object Class to Hold
      Uniform Resource Identifiers (URIs). M. Smith. January 1997. (Format:
      TXT=8757 bytes) (Status: PROPOSED STANDARD)

                    Harald

---

From: "Al Costanzo" <[email-masked]>
Date: Wed, 7 Jun 2000 09:24:09 -0400

> geographic location information about machines.

Terry, everyone...

I am not sure if there will ever be ONE TRUE way.   But your point was taken
when the draft was written. This is why DNS was chosen in the first place.
Every ISP needs to run DNS and already has to administer it. Does/will every
ISP administrate and use LDAP? I think not.

The object of this draft was to 'simplify' the introduction of geographical
data for machines. I see geographic RRs (and there are a few [ not just
LOC ] ) seldom used.

Although GL is designed to be machine read, it is also easily to visually
reference the machines location and easy to administer. Why add complexity?

Let me also address a few other points that I have read on this list:

Eric:

I do not think of GL data as external. I see it as missing from DNS... and
it is my opinion it belongs there/here.

>The *ONLY* way you
>a way for every postal system in use today to be consolidated

I do not agree... LOC is only as valid as the person using the GPS to figure
out what belongs in there what good is the GPS data if it is entered wrong
by an administrator that is a wiz at computers but can't use a GPS?

GL is only as valid as the person inputting the data as well, but everyone
know their postal address (I hope).  Any address may be input in the qouted
string argument and every country has a ISO country code, so evern if the
country does not use postal codes, the country and region are easily
definable.

------

To address the issue of dynamic ips...  if you wanted to enter GL
information you would simply adjust the 'Hierarchical Locator' to an
imprecise location. Most dynamic ips come out of pools that service a region
or area, you would mearly use as much data as available for the ip and you
would know a 'general area' of the machine.

------

As far as the Astronomical Location is concerned (being silly). This was
included in the draft because the issue was raised - on this list - 'How
would you address a computer on a space station? or Mars?'

First the Astronomical Location (AL) would be defined by a request going to
and being approved by IANA.

To define the GL RR you would merely use the new AL and the country code
would be set to the country of origin of the device. The quoted string would
be used for the rest of the information.

Regards,

Al

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 07 Jun 2000 09:01:29 -0400

From:  "Eric A. Hall" <[email-masked]>
Message-ID:  <[email-masked]>
Date:  Tue, 06 Jun 2000 13:54:21 -0700
To:  Terry Lambert <[email-masked]>
CC:  Harald Tveit Alvestrand <[email-masked]>,
            Jerry Scharf <[email-masked]>, [email-masked]
References:  <[email-masked]> <4.3.2.7.2.20000603111423.037b0d88
@dokka.kvatro.no> <[email-masked]> <[email-masked]> <393D
[email-masked]>

>My belief is that DNS is not viable as a generic directory service. The

Agree.

>lack of authenticated vs anonymous queries alone precludes this usage.

DNS security provides for signing and thus authenticating queries.

The worst problem is lack of approximate/pattern/range searching,
lack of multiple attribures to search on, etc.

>want different answers depending upon who's asking each of the specific

Any data you wanted to store could have a version field built in.

>data can point to LDAP objects if large amounts of detail (or LDAP

Donald

---

From: Alfred Novacek <[email-masked]>
Date: Wed, 7 Jun 2000 22:09:11 +0200

Terry Lambert <[email-masked]> wrote:
[...]
>geographic location information about machines.
[...]
>all is a seperate question.
[...]

That's the point where my doubt whether GL RRs (or another mechanism that
uses semistatical services like DNS) will really be usefull for getting
location information:

There is at least one application that may not be implemented efficiently
this way: the case of the mobile user that is determining its position via
GPS (or a similar device) and that wants to make this information available
to others (e.g. the owner of a shipping agency that wants to steer his
fleet the most efficient way).

Maybe extensibility of the scheme may be of benefit, too; e.g. user service
might want to know the telephone number of the user (why maintain all these
informations in different places?); but then, security considerations (who
shall be allowed to see which information) come into play, too.

Any solution that doesn't consider such cases simply cannot be the "One
True Way".

A better approach might be to ask the host itself. If predefined protocols
shall be used, LDAP and HTTP are suitable candidates (use some predefined
URL like
   http://target-host.example.com/cgi-bin/location
that delivers a document of "GL" XML DTD). If efficiency of communications
is required, some simple UDP-based request-response protocol may be
designed. Either way, implementing and deploying will be much faster than
changing the way DNS works (by defining a new RR).

Any of these protocols will cover the cases of the mobile user and of the
local user that wants to provide this information himself. However, when
central administration is desired, either a way to centralize configuration
(and/or preconfiguration) or a way to redirect these queries to a central
server must be provided (the SEE RR proposal might be usefull to provide
this; however, redirection mechanisms of existing protocols may be used,
too).

BTW, allowing for various ways to provide "GL" information will eliminate
another problem, too: If only DNS-Admins may enter this information, and
many of them (I confess I'm one of them) see only the burden this places on
them, at least the quality of the information provided will suffer (lazy
updates, ...); in the worst case, the proposal simply won't take off (I
think that's one reason why LOC failed).

To summarize, I don't think that the DNS is a good place for location
information; and a GL RR definitely isn't the "One True Way" to provide it.

Sincerely Yours - Alfred Novacek

------------------------------------------------------------------------
Dipl.-Ing. Alfred Novacek
Institute for Data Processing in Business Administrations,
     Economics and Social Sciences
Johannes Kepler University Linz / Austria
E-Mail: [email-masked]
        [email-masked]
WWW: http://www.idv.uni-linz.ac.at