Subject: RE: [Enum] ENUM Requirements

From: [email-masked]
Date: Wed, 1 Dec 1999 09:23:42 +0100

I would like to provide you with some comments giving some additional information on number structures
marked with *WL.

[email-masked] on 30.11.99 21:25:35

 To:      [email-masked], [email-masked], 
          [email-masked]                                       
                                                              
 cc:      (bcc: Wolfgang LAUTENSCHLAGER/DE/ALCATEL)           

 Subject: RE: [Enum] ENUM Requirements                        

> Are 1 800 numbers or the UK version of toll free legitimate
> e164 numbers or is this national numbering plan specific.
> I agree these numbers are essential to resolve but what
> other classes of numbers must resolve as well... 900 ?

Freephone numbers are not E.164 addresses, but I think
it's pretty clear that the mechanism developed by enum
will work just as well in other domains (say, nanpa.int).
The problem, of course, is that applications would need
to be able to determine whether a number exists
within the E.164 domain or a national numbering plan
domain.

*WL: I disagree that Freephone numbers are NO E.164 addresses.
Freephone and any other service numbers are E.164 numbers as well. If you look
on the E.164 number structure, it consists of CC (not relevant in this case as
it is a national number), the NDC and the SN (subscriber number). According to
E.164 a NDC as such can be a trunk code, ..., and a service code as well.
800 numbers and 900 numbers and other digit strings which identify
a specific service (as defined by the national regulatory body) are a NDC.

> Is it appropriate at this time to formally Require ENUM to coordinate
> efforts with ITU SG2 etc?

Require?  I should think not.  At any right, the only
body I know of which now has a work item on E.164->IP
address resolution is ETSI Project TIPHON.  Eurescom has
a very large telecoms database project, but I think
that it's scoped somewhat differently.

Melinda
--
Melinda Shore
Member of the Scientific Staff
Nokia IP Telephony
127 West State Street
Ithaca, NY  14850
+1 607 273 0724 (office)
+1 607 275 3610 (fax)
+1 607 227 4096 (mobile)
[email-masked]

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

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

---

From: [email-masked]
Date: Wed, 1 Dec 1999 09:54:05 +0100

Sorry,
one more time,I have forgotten to introduce myself:

Wolfgang L.
--
Wolfgang Lautenschlager
Product Management
Alcatel SEL AG
Lorenzstr. 10
D70435 Stuttgart
Germany
+49 711 821 47652 (office)
+49 711 821 43273 (fax)
[email-masked]

Wolfgang LAUTENSCHLAGER
01.12.99 09:23

To:   [email-masked]
cc:   [email-masked], [email-masked], [email-masked]
Subject:  RE: [Enum] ENUM Requirements  (Document link: Wolfgang LAUTENSCHLAGER)

                                                              

                                                              

Melinda

---

From: BARNOLE Valerie CNET/DAC/ISS <[email-masked]>
Date: Wed, 1 Dec 1999 18:39:20 +0100

As a delegate in Q.1/2 in SG2, I would like to give some comments on the
issues raised in Richard's and Melinda's mails :

Please see my comments in italic letters inserted in the mail below. I
apologize if I just say things that everybody knows.

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: Richard Shockey [ mailto:[email-masked]
<mailto:[email-masked]> ]
Date: mardi 30 novembre 1999 22:10
À: [email-masked]; [email-masked]; [email-masked]
Objet: RE: [Enum] ENUM Requirements

>within the E.164 domain or a national numbering plan

I don't think this is a problem. Its clear to me now that specific national
numbering plan features could be zoned specifically for that purpose in
much the way you suggest if the zone .1 points to a specific delegation for
.8.0.0.  or .8.8.8 etc. What I was not clear of originally was that
multiple digits could combined in this way.

I think we all want to avoid clients having any prior knowledge of national
plan specific features.

    1 800 numbers are E.164 numbers. I explain : an E.164 number (max length
= 15 digits) has the following structure :
CC (country code, 1 to 3 digits = 1 for the USA) followed by a NSN (national
significant number, max length = 12 digits, here = 800....).
But they are names, and not addresses, so in order to reach the endpoint,
such a number (with the function of a name) has to be translated into an
address, currently another E.164 number (with the function of an address).

>that it's scoped somewhat differently.

You're right .. require is not the right word though I think this proposal
will closely examined by  IETF "sister" standards bodies.

   ITU-T Question 1/2 ("applications of numbering and addressing plans for
fixed and mobile services", will deal also with naming) is part of the
Working Party 1/2 ("numbering, routing and global mobility") which is itself
part of Study Group 2 ("network and service operation). During our last
WP1/2 at the end of september 99, meeting, we created a project named
"Numbering, naming and addressing for interworking between E.164 and IP
address-based networks". 
We also discuss the need of coordinating our work with entities like IETF
and ICANN. In this view, with inputs from the ITU policy and strategy
department, we proposed the ITU to invite a meeting "IP and Telecoms
Interworking Workshop" from 25 to 27th january 2000, in Geneva, focussed on
numbering, naming, addressing and routing for convergence of telecoms and
IP. This meeting is widely open to IETF, ICANN or others involved in the
topic.

I do not know if some official invitation has been already sent, but we hope
IP people to attend in order to meet, identify key issues and progress
together.We also expect IETF and ICANN to give us inputs on an agenda item.
I agree that "require" is not a correct and happy word to start a fruitful
coordination !

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

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

---

From: Richard Shockey <[email-masked]>
Date: Wed, 01 Dec 1999 12:41:47 -0600

Thank you for writing!

>"Numbering, naming and addressing for interworking between E.164 and IP

Is there any documentation on the project scope?

>I agree that "require" is not a correct and happy word to start a fruitful

This is the first I've heard of a meeting... If there is a formal 
announcement of this it would be very appropriate to post on the main IETF 
discussion list [ [email-masked] ] after checking with the ENUM AD and 
official IETF liaison with the ITU Scott Bradner [ [email-masked] ]

Richard Shockey
Shockey Consulting LLC

---

From: Larry Cox <[email-masked]>
Date: Wed, 01 Dec 1999 13:58:35 -0700

It may be important to re-evaluate some of the mapping strategy in relation
to E.164 numbers. It is important to keep in mind that an E.164 number is a
numeric name constrained to a specific hierarchical pattern, not an
address, and is translated into an address progressively based on country
codes, a national numbering plan, and local configuration. For numbers such
as emergency call (typically 911 in North America) and toll free (800 or
..), the address may vary depending on the location where it is
translated, the time of day, or other variables. Since what we are
translating is a name, not an address, we must be careful to not constrain
our system too tightly. If the address associated with an E.164 number
changes at 6 hour intervals (for toll free numbers this is not uncommon),
we must not route calls irrationally. We should also not break the system
that chooses a destination for the call based on the calling party number
if this can be avoided. If I call an 800 number to order a pizza and due to
the way the call is routed I find myself talking to someone in Los Angeles
when I want my pizza delivered in Atlanta, the functionality of the system
has been compromised.

Larry

>MediaGate iPost VoiceMail and Fax 800.260.4464

======================================

Larry Cox
Senior Software Engineer

Hypercom Network Systems Inc.      Phone: (602) 504-4657
2851 West Kathleen Road            Fax: (602) 504-4711
Phoenix, AZ 85053                  Web: www.hypercom.com
USA

---

From: "Anne Brown" <[email-masked]>
Date: Fri, 3 Dec 1999 10:12:47 -0500

Christian,

-----Original Message-----
From:	Christian Huitema [mailto:[email-masked]]
<mailto:[mailto:[email-masked]]> 
Sent:	November 30, 1999 5:40 PM
To:	Richard Shockey; [email-masked];
<mailto:[email-masked];>  Brown, Anne [NORSE:6L47-I:EXCH];
[email-masked] <mailto:[email-masked]> 
Subject:	RE: [Enum] ENUM Requirements

At 03:09 PM 11/30/99 -0600, Richard Shockey wrote:
	> [.. snip ..]

We debated this at length in DC, and we also debated it in previous
instantiations of the BOF. Dial plans are here to stay, and it is very
important to accomodate them.  Joe User or Jane Average have no idea of what
E.164 means. Frankly, how many times do you see phone numbers on business
cards written with the explicit "+" convention, as in "+1 973 829 5555"? You
are much more likely to see the number printed exactly as the person would
have dialed it, using the local plan. And you may bet that these numbers
would be the most likely input to any translation system.
I don't think that we can expect a global mapping service to have in its
scope how local or private numbers are mapped to global numbers.  As well,
the ENUM service should not require querying clients to have knowledge of
all numbering plans and structures, only its local plan.
I think that the right architecture should assume that dial-plans, be they
national or private, are mapped into specific subtrees of the DNS, and that
the number resolution software is parametrized by the name of the
"translation root." Then, we have to make sure that we can use the right
technique, e.g. point *.0.0.dial-plan.fr to *.e164.int using DNS aliasing.

Is this not a local matter, and thus not subject to standardization?  Or are
you proposing that we design a method, but its application is for other
groups?

The usage of an explicit parametrization of the subtree has another
advantage.  It allows for the user to choose between parallel mapping trees,
thus allowing for competition between different mapping systems and avoiding
the monopoly capture of a single root.

This facility is important.  However, I still think the scope of this is
national or even regional and perhaps not for the ENUM group.  How each
sub-tree is mapped should be done in some other group.  I would suggest even
outside the IETF.
*	Christian Huitema

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

Regards,

Anne Brown
Nortel Networks