Subject: Re: requesting change of status for RFC 1876

From: Jerry Scharf <[email-masked]>
Date: Tue, 01 Dec 1998 09:10:02 -0800

I like LOC alot, and don't want to see it depricated, but I don't yet see a 
need to move this to PS. My memory was that LOC was done so that people could 
get locations into network management systems and the like. I have not seen 
this happen, and I also see the whole NMS world developing LDAP fever. The 
coupling between NMS and DNS has been bad and is not getting closer, so 
directories/LDAP seem to be the NMS method of choice. Perhaps someone needs to 
talk to the DEN folks and make sure there is explicit duplication between LOC 
and DEN. (If peopel want me to, I can make that contact.) Otherwise LOC will 
become obsolete.

Does anyone know of a case where someone said "I'd use LOC if it was a PS but 
not now?" If so, I have no great objection to moving it forward (even one 
strong desire for a product would be enough for me). If we talk to the DEN 
folks and having it be a PS makes it more likely that LOC be accepted as the 
location form for DEN, that would also be a reason. Otherwise, it seems like 
an exercise in IETF gymnastics.

jerry

---

From: Paul A Vixie <[email-masked]>
Date: Mon, 30 Nov 1998 10:43:58 -0800

> From: [email-masked]
> Date: Mon, 30 Nov 1998 08:40:08 -0800 (PST)
> 
>> from experimental to proposed standard
> 
> I'll add another affirmative hum to this request w/ a minor
> editiorial nit.  Please change the numbers/names from 
> ones that might be used at ISI.  There are numbers and domain lables
> that are explicitly for documentation use.

diffs, please?  or more specific change requests?

(i received crawdad's changes and will incorporate them.)

---

From: Christopher K Davis <[email-masked]>
Date: 30 Nov 1998 13:15:19 -0500

Paul A Vixie <[email-masked]> writes:
> [let's move RFC 1876] from experimental to proposed standard

Part of the move to PS should include cutting out the non-CIDR-aware
network-based search algorithm and replacing it with the simpler and
more intuitive domain-based search algorithm.

<URL:http://www.ckdhr.com/dns-loc/using.html> has some notes on why the
old one didn't work, and a description of the new one (which is already
implemented in VisualRoute and a couple of my own tools).

Here's a first cut at the new RFC wording.  Suggestions appreciated.

[Another other thing to fix in 1876 is the author addresses. :-]

================================================================

The original version of this specification published in [RFC 1876] used a
network-based search method based on [RFC 1101].  Unfortunately, RFC 1101's
applicability to CIDR blocks, supernets, and similar configurations is not
very good, and no suitable replacement has yet been developed.

Instead of the older search method, the following simpler method is
suggested for applications that wish to look for additional LOC RRs that
might apply to a given domain name.

When starting with a fully-qualified domain name, first try the full
name (following CNAME records as usual); if the query succeeds, return
that LOC data. If the query fails, try again after stripping off the
first component of the name, but without following CNAMEs; this avoids
problems with non-terminal CNAME records.  If that query fails, strip
the first two components (and so forth) until either a LOC record is
found, or the DNS root is reached.

When starting with an IP address, do an in-addr.arpa lookup, then use
the name returned to search as above.

The major drawback of this scheme is that it can result in a large
number of queries for LOC records for "com", "net", and other top-level
domains, further loading the root nameservers (especially when doing
batch lookups).  This can be alleviated by caching negative results
(either in the application or in the nameserver it sends its queries
to) and by adding LOC records (which will be cached in the normal DNS
manner) for such domains.  (For most country code domains, I suggest
using the coordinates of the center or capital of the country, with an
appropriate size field; for domains with worldwide users, I suggest
using 0 N 0 E and a size field of 2000000000m to indicate "the whole
world".)

-- 
Christopher Davis * <[email-masked]> * <URL:http://www.ckdhr.com/ckd/>
Put location information in your DNS! <URL:http://www.ckdhr.com/dns-loc/>