Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 4 Feb 2000 17:40:45 -0500

Mark Foster [mailto:[email-masked]] wrote:

> While the actual zone delegation scheme is presumably out of 
> ENUM scope, I
> certainly agree with the notion of isolating clients from the 
> details of the
> structure, as it will certainly evolve.   The default option 
> is to make no
> delegation structure assumptions and always place a dot 
> between every digit.

But is this strictly true? I mean, is whatever evolution that's about to
befall on us going to make individual country codes hierarchical among
themselves, for example? I'm asking because I don't know.

As things are now, a 4 most significant digit can indicate Sweden, the Czech
Republic, or the UK. A 2 can indicate Morocco, Egypt, or Greenland(!?). A 3
can indicate France, the Netherlands, or Italy.

So the question is, will the individual-digit hierarchy be meaningful or not
in the future?

I guess the general consensus is that it will be making more sense, rather
than less sense than it already makes? A dot between digits requires each
digit to be meaningful hierarchically, yes?

Bert
[email-masked]

_______________________________________________
ITU+IETF mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/itu+ietf

---

From: Keith Moore <[email-masked]>
Date: Fri, 04 Feb 2000 18:36:47 -0500

> So the question is, will the individual-digit hierarchy be meaningful or not

yes.  you will always be able to represent the E.164 delegation hierarchy
using a DNS tree where each digit is a separate DNS label.   this would
not necessarily be the case for a DNS tree where there were some 
multiple digit labels.  that's why the one-digit-per-label representation
is preferred.

the nice thing about doing it this way is that the structure of phone
numbers is reflected in the DNS tree, and can change from time to time,
rather than being embedded either in lookup software or in users' minds.

so for an example, to look up +1 865 974 3126

1. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to the DNS root 

<<< DNS root returns "I have no answers for you, but domains 
    ending in .e164.net can be looked up at any of the following servers..."

    (list of servers for lookup of top-level e.164 prefixes follows)

    (this assumes that the root server also serves .net, as is
     currently the case for at least some of the root servers)

2. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the
   DNS servers listed for .e164.net

<<< that server returns "I have no answers for you, but domains
    ending in .1.e164.net can be looked up at any of the following
    servers..."

    (list of servers for north america follows)

3. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the
   DNS servers listed for .1.e164.net

<<< that server returns "I have no answers for you, but domains
    ending in .5.6.8.1.e164.net can be looked up at any of the 
    following servers..."

    (list of servers for Knoxville area, Tennessee, US follows)

4. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the
   DNS servers listed for .5.6.8.1.e164.net

<<< that server returns "I have no answers for you, but domains
    ending in 3.4.7.9.5.6.8.1.e164.net can be looked up at any of
    the following servers..."

    (list of servers for the University of Tennessee, Knoxville
     campus, follows)

5. send a query for 6.2.1.3.4.7.9.5.6.8.1.e164.net to one of the
   DNS servers listed for 3.4.7.9.5.6.8.1.e164.net

<<< that server returns "here are the records for 
    6.2.1.3.4.7.9.5.6.8.1.e164.net"

note that

a) the query is the same at every step
b) it's not necessary to make a separate query for each digit -
   each server returns a referral for the longest DNS suffix
   matching the query.
c) if the structure of e.164 delegation changes, this change
   can be reflected in DNS without any changes whatsoever
   to client code.    for instance, another level of delegation
   could be added for the +1 865 974- prefix, or the e164.net
   servers could be taught to lookup north american numbering
   plan area codes under +1, and delegate each area code to
   to the appropriate country's DNS servers, or directly to
   servers for those area codes.  the client code doesn't have 
   to know or care how this is done.
d) in practice, the results of the first two or three or four
   queries are likely to be in a local cache, thus most lookup
   will not require that many queries.