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

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 4 Feb 2000 11:39:54 -0500

Manfredi, Albert E [mailto:[email-masked]] wrote:

> > because only north americans think country codes and city 
> > codes are clearly
> > delineatable in a universal way?
> 
> Not so. That's what I tried to point out using the European 
> number example.
> 
> And if some E.164 number in the future becomes hierarched(??), you can
> always add in dots. The result will never be ambiguous.

What I meant was, "And if some E.164 number in the future becomes even
_more_ hierarched, ..."

Adding dots, as long as the numbers are in consistent order, is no problem
at all.

Bert
[email-masked]

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Feb 2000 11:44:19 -0500

This whole thing starts to fall apart when LNP is introduced.
If the EU ever mandated LNP between countries, even that would
break down.  

I guess the issue is: we know that the structure of E.164
is breaking down, we can only speculate how fast it disintegrates.
We know that it eventually disintegrates into a data dip on the
entire E.164, so should ENUM define something that works for some
undefined interim time period or not?  If we decide that it should
optimize some level of structure, how deep should it go?

It seems to me that it is NOT a good idea to have something between
2.1.2.1.5.5.5.2.1.2.1.e164.int and 12125551212.e164.int, because
as the structure disintegrates, both mechanisms continue to work,
but an intermediate one -- say 5551212.212.1.e164.int -- fails when
cross area code LNP is mandated. 

The problem is that even if the DNS were reorganized, the CLIENTS
would have to be reprogrammed, since they have to know to form
the query as, say 2125551212.1.e164.int.  Not a good plan IMO. 

Brian

> -----Original Message-----
> From: Manfredi, Albert E [mailto:[email-masked]]
> Sent: Friday, February 04, 2000 11:30 AM
> To: 'Randy Bush'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Enum] Re: Structure of DNS entry for ENUM
> 
> 
> Randy Bush [mailto:[email-masked]] wrote:
> 
> > > I understand that "e164.int" might become a new global TLD, 
> > but what do mean
> > > the digits of the E.164 number as they are i.e separated by 
> > a dot and
> > > therefore, I suppose, having to point out INDIVIDUALLY to 
> certain IP
> > > addresses.
> > 
> > it is the phone number reversed and the dots are added in a 
> > way that allows
> > dns delegation at any level in that phone number.  e.g.
> > 
> >   phone number is +1 206 780 0431
> > 
> >   look up 1.3.4.0.0.8.7.6.0.2.1.e164.int
> > 
> > this allows the dns 'owner' of
> > 
> >   6.0.2.1.e164.int
> > 
> > (+1 206 all of the seattle area) to delegate
> > 
> >    0.8.7.6.0.2.1.e164.int
> > 
> > to the server set which just handles +1 206 780,  bainbridge island.
> > 
> > this is so it distributes well and hence scales well.
> 
> True, and the reverse order is used because, as Steven Lind 
> pointed out, the
> hierarchy in the names is opposite that of the E.164 numbers (and also
> opposite that of the IP addresses, I might add).
> 
> However, it's not clear to me why the fields of the E.164 
> number which are
> clearly delineated, such as country code and city/area code, 
> could not at
> least have been kept together, delimited by dots. The long 
> series of dots
> seems a bit excessive?
> 
> One might _also_ argue that as long as e164.int is used in 
> the DNS name
> field, the convention for the stuff up front be in accordance 
> with E.164?
> 
> I think it would be far clearer, and no tremendous problem, to show
> 
> +1 206 780 0431
> 
> as 1.206.7800431.e164.int,
> 
> and a euro-style number like
> 
> 39 06 3295887 as
> 
> 39.06.3295887.e164.int.
> 
> I mean, the whole point of DNS names was that they be clear 
> to a human, yes?
> 
> I still think, though, that using the DNS field for AESAs, 
> peer to the IP
> address field, would be a useful feature in addition to this naming
> convention.
> 
> Bert
> enum mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/enum
>

---

From: Scott Bradner <[email-masked]>
Date: Fri, 4 Feb 2000 13:34:49 -0500 (EST)

> What I think is truly "unworkable" (a favorite word here) is the current
> plan, which requires every normal human to write down the phone number on a
> piece of paper before being able to type it in, in reverse order, with all
> the dots.

oh, here is the basic disconnect - the all-them-dots version is what
is sent to the DNS it does not have to be what the user types (in
fact it would be quite broken if the user had to type any of this)

Scott

---

From: "Rosbotham, Paul" <[email-masked]>
Date: Fri, 4 Feb 2000 15:12:41 -0000

Alain,

My understanding is that it was chosen to use dots between each individual
digit in order that the client software does not need to have a detailed
knowledge of E.164.  For example, if you were to break the number below into
administrative "domains", you would have

2804.6265.8.46.e164.int (I think), on the basis that;

46 is country code for Sweden
8 is area code for Stockholm
6265 identifies the exchange (Tele2 I guess)
2804 identifies the line on the exchange.

However, to do this you'd need to know that 46 is a 2 digit country code,
that area code 8 within Sweden is a 1 digit code etc, which would be far too
onerous.  On the other hand, if you dot each individual digit of the E.164
number, the client software won't need to know the E.164 structure, and the
routeing to the correct server would be handled by DNS, eg the server for
.164.int would know that .4.6.e164.int should be sent to a Swedish server,
which in turn would know that .8.4.6.e164.int would be handled by a
Stockholm server.

Hope this clarifies (hope it's correct!)

Paul

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, February 04, 2000 1:37 PM
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	[Enum] Structure of DNS entry for ENUM
> 
> Dear All,
> 
> I attended the last ITU+IETF workshop (Geneva 25-27 Jan 2000) and I have
> still a question regarding the presentation made by R. Shockey.
> 
> It's about the linkage between E.164 resources and IP names (or addresses
> here ?)
> 
> He gave an example :
> "query for 2.8.0.4.6.2.6.5.8.6.4.e164.int"
> I understand that "e164.int" might become a new global TLD, but what do
> mean
> the digits of the E.164 number as they are i.e separated by a dot and
> therefore, I suppose, having to point out INDIVIDUALLY to certain IP
> addresses.
> In the example, the E.164 number is a number in Sweden, country whose
> E.164
> country code is 46, therefore, "46" has a meaning (i.e. look at the
> swedish
> numbering plan, not to another one), but the digits "4" and "6" taken one
> at
> a time do not mean anything.
> 
> Could somebody explain me this issue ?
> 
> Thank you in advance
> 
> Alain Doisneau : mailto [email-masked]
> 
>

---

From: Mark Foster <[email-masked]>
Date: Fri, 4 Feb 2000 16:19:57 -0600

IMHO, it already has started to disintegrate at the country code level for
certain countries.  In a few weeks, the FCC is expected to release a number
conservation order that will mandate number pooling in the US.  This will
mean that all new number block assignments to carriers will be made in
smaller increments using LNP as the activation means, instead of by unique
NPA-NXX level assignments in the LERG.  This will dramatically increase the
proportion of numbers routed via the LNP database over and above those
simply resulting from service provider competition.

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.

R, Mark
-------------------------------------------------------------
Mark D. Foster                  | EMAIL: [email-masked]
CTO                             | NeuStar, Inc.
TEL: +1 202 533 2800/2702       | FAX: +1 202 533 2975
1120 Vermont Ave NW, Suite 550  | Washington, DC 20005

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, February 04, 2000 11:44 AM
To: 'Manfredi, Albert E'; 'Randy Bush'
Cc: [email-masked]; [email-masked]
Subject: RE: [Enum] Re: Structure of DNS entry for ENUM

Brian

---

From: "Shaw, Robert" <[email-masked]>
Date: Mon, 7 Feb 2000 14:37:04 +0100

> From: Keith Moore [mailto:[email-masked]]
> Sent: Monday, February 07, 2000 2:10 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry 
> for ENUM 
> 
> 
> it could be either .int or .net and still work just as well.
> (assuming that nobody has bought e164.net by then!)
> 

hmmm... 

some folks called netnumber.com have e164.com

Peter Lothberg has e164.net

Lucent has e164.org

I wonder what would be the result of a UDRP challenge 
to these names (I think I'm joking...) 

Bob

---

From: "Anne Brown" <[email-masked]>
Date: Mon, 7 Feb 2000 09:41:48 -0500

FYI.  I believe Lucent established e164.org for enum development testing and
would be willing to give it up to whomever it makes sense to do so.

Regards,
Anne

		-----Original Message-----
		From:	Shaw, Robert [mailto:[email-masked]]
		Sent:	February 07, 2000 8:37 AM
		To:	'Keith Moore'
		Cc:	[email-masked]; [email-masked]
		Subject:	RE: [ITU+IETF] RE: [Enum] Re: Structure of
DNS entry for ENUM

		hmmm... 

		Lucent has e164.org

		Bob

---

From: BARNOLE Valerie CNET/DAC/ISS <[email-masked]>
Date: Mon, 7 Feb 2000 15:53:52 +0100

I do not know where is the right place to discuss about the e164.foo to
choose, but the discussion will have to take place somewhere one of these
days.

From Bob Shaw's answer, it seems to me that the easy solution is to use
e164.int, because I think that ITU, which has been allocated .int (I think
so), is not using it by now. Am I right ?
Politically, from a naive point of view, it should hurt nobody because ITU
is already in charge of the international E.164 numbering plan (I do not
omit the delegation to the different regulating authorities through the
allocation of the geographical country codes). but maybe I am missing
something ?

As I have no real IP naming background or experience with IP names problems,
I wonder if it is safe to use e164.foo if the domain e164 has already been
bought by other entities under other GTLDs.

Your comments are welcome. 

end of message
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

Valérie Barnole
FT.BD/CNET/DAC/ARS
tel. : + 33 1 45 29 58 39
fax : + 33 1 46 29 31 42

[email-masked]

-----Message d'origine-----
De: Shaw, Robert [mailto:[email-masked]]
Date: lundi 7 février 2000 14:37
À: 'Keith Moore'
Cc: [email-masked]; [email-masked]
Objet: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM 

hmmm... 

Lucent has e164.org

Bob

---

From: James Yu <[email-masked]>
Date: Mon, 7 Feb 2000 11:48:16 -0600

I agree.  But I'm replying to Randy's message that each consortium/domain
may use one TLD (or including the 2nd level domain) for its own use.  That
consortium/domain may only handle certain phone numbers, not all of them.

We should be looking for a scheme that can cover the aspects we can think
of.

James
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, February 07, 2000 12:12 PM
> To: James Yu
> Cc: 'Randy Bush'; Richard Shockey; [email-masked]; [email-masked]
> Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM
> 
> 
> 
> 
> James Yu wrote:
> > 
> > This means that the client would need to know which 
> consortium/domain to use
> > when sending the DNS query.  It may be fine if the client 
> only handles calls
> > within a consortium/domain.  But it won't be true for all 
> the clients.
> 
> I don't think we're trying to solve all aspects of the general problem
> here. I think our job is to start with a tld, and from there, 
> figure out
> how to formulate the query to get back some kind of useful response.
> Deciding who owns these tld's, and how to configure them in 
> clients, is
> important but not what we are solving here.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg                       200 Executive Drive
> Chief Scientist                             Suite 120 
> dynamicsoft                                 West Orange, NJ 07052
> [email-masked]                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
>

---

From: [email-masked] (Richard D G Cox)
Date: Mon, 7 Feb 2000 18:13 +0000 (GMT Standard Time)

Richard Shockey <[email-masked]> wrote:
> realistically we can use any domain and TLD we can agree on....

Indeed.  Using e164 is something of a hostage to fortune; it's not _that_
long since the standard was E.163 rather than E.164!  At any time ITU-T
could propose a new set of standards and a new E. number to go with them.

Perhaps - given the significance of this - we should consider whether a
separate (virtual) country-TLD is called for here?  Of course, there's
nothing to stop us continuing to use the e164.int as a placeholder in our
discussions in ENUM!

Anne Brown <[email-masked]> replied to <[email-masked]>:

>> Please clarify "the owner of the telephone number" in Section 3.11.
>> Is it the subscriber that is assigned the telephone number or the
>> service provider that currently serves that number?

> Section 3.11 on Privacy states that "The system MUST allow the owner
> of the telephone number to control the information which prospective
> callers may receive."  I recommend replacing the text with "The system
> MUST allow the user to whom the telephone number was assigned, the
> ability to control the information...".

This potato is hotter than you might have realised: we haven't yet defined
the "user" (of the telephone network services) with sufficient clarity to
avoid the sort of dispute that some of us are expecting/dreading.

I don't have an answer to offer that I'm happy with, but give thought to
the sort of situation where a paging bureau, message bureau, fax-to-email
service etc. set up facilities and then offer them to downstream users.
The bureau (or service provider) may not (depending on the country) be
subject to the mandatory number portability requirement, but will normally
have been assigned a block of telephone numbers (usually delivered using
DNIS/DDI over a T1 or an E1) which they then sub-allocate to users.

Which is to be the "user" for the purposes of Section 3.11?  It's possible
to make an arbitrary decision based on any one specific circumstance, but
far harder to define an algorithmic rule that scales up or down to fit all
the circumstances we are likely to come across!

Richard Cox
Mandarin Technology, Penarth, UK
+44 (29) 2031 1131

---

From: [email-masked]
Date: Mon, 7 Feb 2000 13:36:57 -0600

> 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 ....

Alas, it's just not that simple anymore, especially
when you take things like NAT into account.  An E.164
address represents an endpoint (or user), but it
unfortunately cannot reliably represent an IP address.
There's a great big disconnect there, but fortunately
if we accept the notion that the E.164 address is
mapping to something else (like an H.323 gatekeeper),
it gives us a leg up on the NAT problem.

Melinda
-- 
Melinda Shore
Nokia IP Telephony
127 West State Street		"Software longa,
Ithaca, NY  14850			hardware brevis"
+1 607 273 0724 (office)
+1 607 275 3610 (fax)
+1 607 227 4096 (mobile)
[email-masked]

---

From: "Lind, Steven D, ALARC" <[email-masked]>
Date: Mon, 7 Feb 2000 15:19:07 -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

800 and 700 numbers are E.164 numbers. Fully qualified, they would be +1 800
xxx xxxx or +1 700 xxx xxxx. Other countries have similar free phone
services with their own set of E.164 numbers.

Steve Lind
---------------------------------------------------------------
Steven D. Lind                   Tel: (973) 236-6787
AT&T                             Fax: (973) 236-6452  
180 Park Ave., Bldg. 2            e-mail: [email-masked]
Florham Park, NJ 07932                 
---------------------------------------------------------------

> From:	David Oran [SMTP:[email-masked]]
> Sent:	Monday, February 07, 2000 2:28 PM
> To:	Keith Moore; Randy Bush
> Cc:	Bill Manning; Richard Shockey; [email-masked]; [email-masked]
> Subject:	RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for
> ENUM 
> 
> 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.
> 
> > 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]
> > > > I find this hard to fathom.
> > >
> > > i am not surprised
> >
> > 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: "Anne Brown" <[email-masked]>
Date: Tue, 8 Feb 2000 11:33:31 -0600

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:[email-masked]]
		Sent:	February 04, 2000 6:37 PM
		To:	Manfredi, Albert E
		Cc:	'Mark Foster'; [email-masked]; [email-masked]
		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 +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.