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

["Anne Brown" <[e-mail]>]

For clarification on the reasoning for the single-digit separation of E.164
digits for lookup purposes:

This strategy was conceived in September 1996 with the following goals in
mind:

1.	Implementable by both DNS and LDAP and other repositories (at the
same time, with partitioning depending on service and application
requirements)
2.	Allows lookups -vs- searching (both DNS and LDAP).  A record or
entry can be pin-pointed without white-pages type searching.
3.	Supports distribution of E.164 resolution data by both blocks of
numbers and by individual numbers.  The strategy allows this distribution to
be changed, when required, to reflect current realities.
4.	Alleviates clients from having to know or be able to derive
numbering plan structures and lengths (What a user types or dials is out of
the problem scope)   
5.	Isolation from changes to numbering plan structures and lengths
6.	Supports use of extensions, if required

Regards,
Anne


		-----Original Message-----
		From:	Keith Moore [mailto:[e-mail]]
		Sent:	February 04, 2000 6:37 PM
		To:	Manfredi, Albert E
		Cc:	'Mark Foster'; [e-mail]; [e-mail]
		Subject:	Re: [ITU+IETF] RE: [Enum] Re: Structure of
DNS entry for ENUM

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

		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 [phone]

		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.
		 

		_______________________________________________
		enum mailing list
		[e-mail]
		http://www.ietf.org/mailman/listinfo/enum