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

From: [email-masked]
Date: Mon, 7 Feb 2000 11:50:34 +0100

Dear All,

As I launched this debate, i first of all thank you who had given your
answers and comments.
Among all of them, I appreciate the following for it thoroughly clarified
the issue to me (with the exception of the .net suffix which looks strange -
shouldn'it have been .int instead ?).

Regards

Alain Doisneau : [email-masked]
-----Message d'origine-----
De : [email-masked] <[email-masked]>
À : [email-masked] <[email-masked]>
Cc : [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>; [email-masked] <[email-masked]>
Date : samedi 5 février 2000 01:48
Objet : 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 +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.
>
>
>_______________________________________________
>ITU+IETF mailing list
>[email-masked]
>http://www.ietf.org/mailman/listinfo/itu+ietf
>

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 07 Feb 2000 08:09:49 -0500

> the issue to me 

thanks for the compliment!

> (with the exception of the .net suffix which looks strange -

it could be either .int or .net and still work just as well.
(assuming that nobody has bought e164.net by then!)

I did not suggest .int because some people consider it controversial,
and I didn't want a debate about .int to cloud the explanation of
how DNS lookups of E.164 numbers would work.  And I haven't been 
closely following the enum discussion, so I don't know what's been
decided about this.  But if the people who run .int have no objection 
to defining e164.int, then neither do I.

Keith

---

From: Richard Shockey <[email-masked]>
Date: Mon, 07 Feb 2000 08:48:39 -0600

>to defining e164.int, then neither do I.

An realistically we can use any domain and TLD we can agree 
on....  [number].domain.foo.

Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Feb 2000 08:04:47 -0800

> An realistically we can use any domain and TLD we can agree on....
> [number].domain.foo.

actually, we don't have to agree.  there can be consortia/conspiracies/
brokerages, each covering all or part of the global phone space and each
using its own domain appendage.  an outbound call would try to resolve in
each of the consortia/domains in which it participates in order of
preference.

randy

---

From: Bill Manning <[email-masked]>
Date: Mon, 7 Feb 2000 09:28:23 -0800 (PST)

% 
% > An realistically we can use any domain and TLD we can agree on....
% > [number].domain.foo.
% 
% actually, we don't have to agree.  there can be consortia/conspiracies/
% brokerages, each covering all or part of the global phone space and each
% using its own domain appendage.  an outbound call would try to resolve in
% each of the consortia/domains in which it participates in order of
% preference.
% 
% randy

	hum, so this method works well for the IP space as well, yes?
	your consortia can anchor its IPv4 space in seattle.wa.us. and
	I can stick my address space in shockwave.com; e.g.

	16.172.seattle.wa.us  &
	24.172.shockwave.com

	and all will be well?

	I find this hard to fathom.

--bill

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Feb 2000 09:31:09 -0800

> I find this hard to fathom.

i am not surprised

randy

---

From: Bill Manning <[email-masked]>
Date: Mon, 7 Feb 2000 09:32:01 -0800 (PST)

% 
% > I find this hard to fathom.
% 
% i am not surprised
% 
% randy
% 

	You should be.  

-- 
--bill

---

From: Keith Moore <[email-masked]>
Date: Mon, 07 Feb 2000 12:36:06 -0500

> each of the consortia/domains in which it participates in order of

certainly a possible outcome.  not necessarily a favorable one.
(some folks would disagree about this)

but I've always regarded this as the biggest problem facing enum -
will it be politically possible to map the e.164 number space onto
a single federated database (like DNS) such that:

a) the result is reasonably consistent with the real e.164 world, 
   (and also consistent from one client to another), and
   
b) the results returned from a lookup of a phone number are under control 
   of the owner of that phone number (perhaps via a proxy)

i.e. mostly a technical problem rather than a political one.

but it does make sense to tackle the technical problem first.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 07 Feb 2000 12:43:06 -0500

> > I find this hard to fathom.

well, it would seem odd for IETF to insist on consistency of
meaning for IP numbers (modulo private address space) but not
care about consistency of meaning for E.164 numbers.

seems like users' interests are best served by having a consistent
meaning, everywhere, for both kinds of address.

Keith

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Feb 2000 09:53:20 -0800

> meaning, everywhere, for both kinds of address.

so that's why the internet phyical topology is a simple dag.  wow.  never
thought of that.

the meaning of a phone number or an ip address is the endpoint, not the
routing, not the billing, not how i derive the path to the endpoint, not
....

randy

---

From: Bill Manning <[email-masked]>
Date: Mon, 7 Feb 2000 09:58:18 -0800 (PST)

% 
% > seems like users' interests are best served by having a consistent
% > meaning, everywhere, for both kinds of address.
% 
% so that's why the internet phyical topology is a simple dag.  wow.  never
% thought of that.
% 
% the meaning of a phone number or an ip address is the endpoint, not the
% routing, not the billing, not how i derive the path to the endpoint, not
% ....
% 
% randy
% 
	then just use the e164 RR and go home, your job here is done.

-- 
--bill

---

From: Keith Moore <[email-masked]>
Date: Mon, 07 Feb 2000 13:00:47 -0500

> so that's why the internet phyical topology is a simple dag.  wow.  never

I think you're missing the point.
 
> routing, not the billing, not how i derive the path to the endpoint, not

I agree, but you appear to be confusing the multipath routing problem 
with the database consistency problem.  

I have no problem in principle with having multiple ways to look up
phone numbers as long as, in practice, the meanings are reasonably 
consistent and up-to-date.  but I suspect that it's easier to figure
out how to get multiple parties to share a single federation tree than 
to keep several mutually autonomous trees consistent with one another.

Keith

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Feb 2000 10:07:45 -0800

> consistent and up-to-date.

411?  611?   i.e. for varying values of consistent.  and that's the point.

[ spoil your lunch and think of the interaction of this with dname,  but it
may help your consistency desires ]

randy

---

From: Keith Moore <[email-masked]>
Date: Mon, 07 Feb 2000 13:26:57 -0500

> 411?  611?   i.e. for varying values of consistent.  and that's the point.

these are not e164 numbers.  perhaps it's a good idea to handle these
things, but that is not a compelling argument for multiple lookup services
for e164 space.

in general I would consider such things to be more akin to prefix
handling (i.e. how do you map local dialling conventions onto real
phone numbers) than to phone number lookup.

Keith

---

From: "David Oran" <[email-masked]>
Date: Mon, 7 Feb 2000 14:28:20 -0500

Perhaps because some people want to use enum for resolving telephone numbers
other than e.164 globally-unique numbers, such as:
	800 numbers (really names)
	700 numbers (really names)
	private numbering plans

I agree that if something is really truly a globally unique E.164 number
there should be ony and only one root for resolving them. Unfortunately, you
can't look at a string of digits and know that, unlike an IP address.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Keith Moore
> Sent: Monday, February 07, 2000 12:43 PM
> To: Randy Bush
> Cc: Bill Manning; Richard Shockey; [email-masked]; [email-masked]
> Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM
>
>

---

From: Keith Moore <[email-masked]>
Date: Mon, 07 Feb 2000 14:33:06 -0500

> can't look at a string of digits and know that, unlike an IP address.

and I agree that local/regional dialing conventions have to be supported. 
but I was assuming that they would be supported by some mechanism other 
than the DNS tree used for global E.164 numbers.  

And while you can probably use DNS tricks to handle a lot of local dialing 
conventions, it's not clear that you want to standardize on that approach.
(how do you do intermediate dial tones, for instance?)

Keith