Subject: [Enum] Re: Structure of DNS entry for ENUM

From: Scott Bradner <[email-masked]>
Date: Fri, 4 Feb 2000 08:44:22 -0500 (EST)

> I understand that "e164.int" might become a new global TLD,

in the above ".int" is the TLD, e164 is a second level domain
.int is already a existing TLD

Scott

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

---

From: "Lind, Steven D, ALARC" <[email-masked]>
Date: Fri, 4 Feb 2000 09:01:37 -0500

Cher Alain,

I will try to impart my understanding of the issue. What the ENUM group has
proposed is to take an E.164 number and convert it into a domain name. As I
further understand it, domain names are always parsed "backwards;" that is
the most significant piece of information is at the end of the name, e.g.,
"int" then "e164", etc. That would mean that the E.164 number would be
"spelled" backwards since the most significant digit would immediately
preceed the "e164.int". The proposal that you illustrate takes the most
simplistic approach at converting the number into a domain name, by
inserting periods between every digit. One could insert the periods around
logical groupings of digits, but that would require additional intelligence
within the end systems to do that. They, like most telephone companies in
the past, have said let the end systems not worry about digit grouping and
let the network servers, in this case DNS, parse the digits and associate
"...6.4.e164.int" with a Swedish country code.

I hope this helps.

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

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, February 04, 2000 8:37 AM
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	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: "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]

---

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

> 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:
> 
> > but what do mean
> > 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

---

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

> Sent:	Friday, February 04, 2000 1:37 PM
> Subject:	[Enum] Structure of DNS entry for ENUM
> 
> Dear All,
>

---

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

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

---

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: Dean Willis <[email-masked]>
Date: Mon, 07 Feb 2000 11:52:27 -0600

I second Jonathan's position. I think that there will by necessity be a
generalization of ENUM to allow for privately administered dialing plans.
The obvious way to do this is to define another domain for each private
numbering plan. How a client knows which one to use is somebody else's
problem. Before anyone can get traction there, ENUM needs to move further
along the single-domain E.164 solution path. On the other hand, we do need
to keep in mind the assumption that there WILL be other domains, and not
make any design choices which preclude such an approach.

--
Dean

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: Monday, February 07, 2000 11:12 AM
> 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: 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
> > when sending the DNS query.  It may be fine if the client 
> only handles calls

---

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

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

---

From: "David P. Peek" <[email-masked]>
Date: Thu, 17 Feb 2000 19:21:00 -0500

>At 06:25 PM 2/16/2000 -0600, Dean Willis wrote:
>
>>Yep. Just don't screw the design down in such a way as to PRECLUDE use of
>>enum techniques for dealing with those separate issues.
>>
>>--
>
>Point well raised Dean. I see this as another form of delegation. Internal
>private numbering plans could be resolved within separate zones within the
>appropriate domain.
>
>lets say  x.x.x.x.x.x.x.x.x.x.x.e164.domain.com
>
>Internal gateways or intelligent telephony devices would have some logic
>that understands that certain _dialing_ strings...resolve against a
>different _numbering_ domain than the global E164 proposed by ENUM.
>
>I think this has hung up some people before. Dialing and numbering are two
>distinct things.
>
>The protocol usage would be the same.
>
>One Internal ..One Global.
>

Very good point raised here.  However, I believe we should continue to
focus exclusively on the One Global solution and not try to solve the
Internal methods to solve private numbering plans using this DNS solution.

It certainly is possible but wouldn't it require us to define additional
NAPTR records and even then maybe not solve the entire private numbering
requirements?    For example, I believe the private numbering solution
should be
capable of support down to the user  level.  This will require the
identification of the source
making a query and DNS isn't really good for that.   A method discussed
with memebers of the VMA Technical Working Group is one that addresses the
private numbering solution at the second tier or ADS (Authoritative
Directory Server) by
making an LDAP query.  This internal private query made by a communication's
platform will retrieve the E164 number associated with the private number
dialed
and then perform a DNS query as described in this "One Global" solution.

An Internet Draft  is being prepared now which describes more details of the
two-tiered approach
that supports the DNS solution we are talking about here in ENUM.   When
available
I'll make sure this group is notified.

Dave

>Maybe this should be documented more clearly.
>
>
>>Dean
>>
>> > From: James Yu [mailto:[email-masked]]
>> > Sent: Monday, February 07, 2000 11:55 AM
>> > To: 'Dean Willis'
>> > Cc: IETF Enum
>> > Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM
>> >
>> >
>> > Dean,
>> >
>> > Agree with what you said; however, I don't consider private
>> > numbering plans
>> > part of E.164.  We are addressing E.164 numbers defined by ITU-TS.
Other
>> > private numbering plans using different domains is a separate issue.
>> >
>> > James
>> >
>> > > From: Dean Willis [mailto:[email-masked]]
>> > > Sent: Monday, February 07, 2000 12:52 PM
>> > > To: IETF Enum
>> > > Subject: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM
>> > >
>> > >
>> > >
>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: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 18 Feb 2000 09:38:29 -0500

David P. Peek wrote:

> For example, I believe the private numbering solution
> should be

This makes perfect sense to me. And one clean way to support the "second
tier" numbering solution might also be to use domains that are unique to the
country where that numbering plan is in effect. For example,
<localtelephonenumber>.telnumbers.fr would accept numbers in the French
plan. So even if you move your appliance around the world, you can continue
to use the numbering plan that appliance is set up to use?

Bert

---

From: "David P. Peek" <[email-masked]>
Date: Fri, 18 Feb 2000 15:44:44 -0500

-----Original Message-----
From: Jonathan Rosenberg <[email-masked]>
To: David P. Peek <[email-masked]>
Cc: Vaudreuil, Greg M (Greg) <[email-masked]>; Manfredi, Albert E
<[email-masked]>; IETF Enum <[email-masked]>
Date: Friday, February 18, 2000 3:08 PM
Subject: Re: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM

>
>
>"David P. Peek" wrote:
>>
>> >Exactly. Another way to look at it is that the system enum is defining
>> >takes two things as input: a phone number AND a domain suffix, and then
>> >returns a list of URIs.
>>
>> Do we really want to require two things (phone number and domain suffix)
as
>> input
>> to the ENUM global solution?   Greg's description of private numbering
>> requires the
>> domain suffix if a DNS solution is to be used to solve the private
dialing
>> plan.
>> This is certainly one way to support private dialing plans.
>
>My point was that our system works for both the global and private
>space. For the global case, the application will know to append e164.int
>or whatever, and for applications that are using private plans, some
>other suffix is supplied by the application. As far as the enum
>component goes, it gets a domain suffix and a phone number. How the
>application decides what that suffix is, whether its e164.int or not, is
>irrelevant for the enum component. It takes that suffix and the number,
>constructs a domain name as per the document, and then goes to DNS and
>gets back URIs for the services available.
>
>-Jonathan R.
>
Thanks for clarifying that.   My fear was opening a can of worms if
we started to address the private space.   I agree with your
statement here.  Thanks   - Dave

---

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Fri, 18 Feb 2000 15:23:17 -0600

As other emails discussed, the 411, 911, 611, *9, and other north-american
short-code information services provided by local telco's are not part of
the E.164 or local _numbering plan_.  They are part of the local _dialing_
plan.  One important characteristic of each of these services is that the
end-point varies by the "location" of the dialer.  It is the client (or
client's agent in the case of a POTS phone connected to a telco switch) that
maps from a dialing plan to a numbering plan.  If you dial 911, you
certianly want a geographically local emergency response department! 

These dialing plans have a use in Internet space, but they need to be
provided by a service better equipped than ENUM to do geographical location.
This can be performed by the client (enter an e164 alias for 911), or a
query to the geographically (emergency response) / politically (city
services) / contractually (phone repair) "local" remapping service for the
current clients definition of "local".

Greg V.

-----Original Message-----
From: Manfredi, Albert E [mailto:[email-masked]]
Sent: Friday, February 18, 2000 2:35 PM
To: 'Jonathan Rosenberg'
Cc: IETF Enum
Subject: RE: [ITU+IETF] RE: [Enum] Re: Structure of DNS entry for ENUM

> gets back URIs for the services available.

But what's more, it is possible that some of these local numbering plan
queries will never be translated over to a query for the e164.int domain at
all. For example, why not permit 911 calls from an Internet applicance, as
long as you're in the US?

I guess that if this scheme works for more than just e.164, more power to
enum.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sat, 19 Feb 2000 17:11:08 -0500

Agree with Dean.

The IP naming convention, for example, already is set up for identifying
locations. You use the city.state.us convention, for example. So what's
wrong with numbers like 911 being followed by telnumbers.fairfax.va.us, just
for example?

Bert

> Sent: Friday, February 18, 2000 6:36 PM
> To: James Yu; 'Vaudreuil, Greg M (Greg)'
> Cc: IETF Enum; Manfredi, Albert E; 'Jonathan Rosenberg'
> For E.164 numbers, I see ENUM as providing a means to find a 
> SIP server or
> gatekeeper that knows how to resolve the given e.164 number. 
> We know pretty
> much how this works.
> 
> DNS solves local problems as awell as global ones. We do this with a
> split-DNS model, or with shadow servers, or local subdomains, or other
> techniques.
> 
> The question is, how does ENUM help you find a SIP server or 
> gatekeeper that
> knows how to resolve the funky local numbers? I suspect that 
> we know how
> this works, too -- one simply makes an ENUM query in an 
> appropriate local
> domain. How? By using the same techniques that apply for 
> local DNS. And
> that's not an ENUM problem, as long as ENUM provides a way for the
> number-to-server-within-a-domain-context problem to be 
> resolved. The current
> proposal seems to handle this nicely.
> 
> I suggest we cease trying to make the problem harder than it 
> is, and simply
> accept the obvious conclusion that the ENUM representation 
> can be used in
> ANY name context with some utility.
> 
> --
> Dean
> 
> > From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of James
> > Yu
> > Sent: Friday, February 18, 2000 5:11 PM
> > To: 'Vaudreuil, Greg M (Greg)'
> > Cc: IETF Enum; Manfredi, Albert E; 'Jonathan Rosenberg'
> > I agree with Greg that 411, 911, 611 or *XX, #XX like numbers are
> > non-E.164
> > numbers.  Those numbers currently are handled by the GSTN 
> switches (local
> > matters if we exclude the mobile roaming scenario).  If IP 
> based networks
> > are to support those service codes or abbreviated dialing codes,
> > the network
> > entity that receives the requests (e.g., the SIP server or GK)
> > must know how
> > to handle those codes if they are "local matters."  In Internet,
> > it may be a
> > problem if there are no standardized procedures in handling those
> > codes.  If
> > the end users can switch the service providers or servers 
> freely and each
> > SP/server may handle the codes differently, there will be end user
> > confusion.  The end users may perceive different 
> treatment/handling or are
> > required to dial different codes when accessing different
> > SPs/servers.  But
> > those are not enum issues.  The enum issue may be whether 
> DNS is needed to
> > resolve those codes.
> >
> > If handling of those codes are "local matters," the client 
> that is to
> > resolve the code may need to append a domain name belonging 
> to the service
> > provider.  If it is a service provider's network entity 
> that is to resolve
> > the code, it probably can resolve it without using the DNS or it
> > can append
> > its domain name if DNS is used.  In this case, no suffix is 
> required.
> >
> > Unless those codes are standardized and "shared" NSs are 
> used to resolve
> > them, then a suffix different from e164.foo and those for private
> > numbering
> > plans as suggested by Johnathan can be used if DNS is used.  DNS
> > can be used
> > to point to the "shared" NSs that has the information about the
> > codes.  The
> > problem is what if the information is location dependent (e.g.,
> > 911 call is
> > to be handled by a PSAP that has the jurisdiction for the
> > caller's/client's
> > geo. location)?   The network (e.g., the SIP server) or 
> client may have
> > pre-provisioned client location/address.  The issue is that the
> > caller/client may call from anywhere other than the default
> > location/address.  In that case, neither the network entity 
> nor the client
> > itself has any clue about the client's current 
> location/address.  Again,
> > this is not an enum issue but an issue for the IP telephony.
> >
> > James
> > > From: Vaudreuil, Greg M (Greg) [mailto:[email-masked]]
> > > Sent: Friday, February 18, 2000 4:23 PM
> > > To: Manfredi, Albert E; 'Jonathan Rosenberg'
> > > Cc: IETF Enum