Subject: [Enum] draft I-D on Infrastructure ENUM Requirements

From: "Lind, Steven D, ALABS" <[email-masked]>
Date: Wed, 13 Jul 2005 22:41:40 -0400

I've put together, 
from the various threads on this list as well as going through several 
documents, what I felt were the requirements people felt were important for 
infrastructure ENUM. I've gathered that into an Internet Draft which I will 
submit sometime tomorrow. It's too late for it to be announced for the Paris 
meeting, but I've posted a copy online at:
<SPAN 
class=210023202-14072005> 
<A 
href="http://www.sdlind.com/draft-lind-infrastructure-enum-reqs-00.txt"><FONT 
face=Arial color=#0000ff size=2>http://<A 
href="http://www.sdlind.com/draft"><FONT face=Arial 
size=2>www.sdlind.com/draft<FONT face=Arial color=#0000ff 
size=2>-lind-infrastructure-enum-reqs-00.txt<FONT face=Arial 
size=2>.
<SPAN 
class=210023202-14072005> 
Health warning: the 
contents are raw and do not imply any consensus on *any* of the 
text.
<SPAN 
class=210023202-14072005> 
Not to put words 
into Patrick's or Rich's mouths, but I think we're still at the green-lighting 
stage. So if there is something you feel is missing from the list, let me know. 
Let's wait a while before we start picking things apart. Once we have what we 
feel is a complete list, we can start discussing the individual items to see 
where we have consensus.
<SPAN 
class=210023202-14072005> 
<SPAN 
class=210023202-14072005>Steve
 
<FONT face="Courier New" 
size=1>--------------------------------------------------------
Steven D. Lind, 
AT&T            Tel: 
973-236-6787
180 Park Avenue, Rm. 
A201       Fax: 360-343-2875
Florham Park, NJ 
07932          e-mail: <A 
href="mailto:sdlind at att.com">sdlind at att.com
<FONT face="Courier New" 
size=1>--------------------------------------------------------
 
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 14 Jul 2005 16:47:47 -0400

Thanks Steve,
 
for doing this job, well done.
I propose this document also as input to the 
VoIP peering BoF
 
-richard

________________________________

Von: enum-bounces at ietf.org im Auftrag von Lind, Steven D, ALABS
Gesendet: Do 14.07.2005 04:41
An: enum at ietf.org
Betreff: [Enum] draft I-D on Infrastructure ENUM Requirements

I've put together, from the various threads on this list as well as going through several documents, what I felt were the requirements people felt were important for infrastructure ENUM. I've gathered that into an Internet Draft which I will submit sometime tomorrow. It's too late for it to be announced for the Paris meeting, but I've posted a copy online at:
 
http:// <http://www.sdlind.com/draft-lind-infrastructure-enum-reqs-00.txt> www.sdlind.com/draft <http://www.sdlind.com/draft> -lind-infrastructure-enum-reqs-00.txt.
 
Health warning: the contents are raw and do not imply any consensus on *any* of the text.
 
Not to put words into Patrick's or Rich's mouths, but I think we're still at the green-lighting stage. So if there is something you feel is missing from the list, let me know. Let's wait a while before we start picking things apart. Once we have what we feel is a complete list, we can start discussing the individual items to see where we have consensus.
 
Steve
 
--------------------------------------------------------
Steven D. Lind, AT&T            Tel: 973-236-6787
180 Park Avenue, Rm. A201       Fax: 360-343-2875
Florham Park, NJ 07932          e-mail: sdlind at att.com
--------------------------------------------------------

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 15 Jul 2005 12:42:17 -0400

Dear all,
 
although Steve did a tremendous job here in such a short time,
IMHO one important set of requirements is still missing in
draft-lind-infrastructure-enum-reqs-00.txt,
namely the Enumservices required for carrier (infrastructure)
ENUM.
 
The Enumservices required for User ENUM can easily be
defined: since User ENUM is an optional service where
an end-user may point to basically any service or application
on the Internet he wants to have associated with his E.164
number, any Enumservice pointing to a valid URI may
potentially be used. The underlying basic "PSTN" service
provided for this E.164 number remains untouched.
 
Even for E.164 numbers only existing in ENUM this
is not a problem, because if these numbers are
dialed on the PSTN, routed to a generic gateway
and no compatible service exists, the valid response 
will be "service not available". This may also
happen on the PSTN if you are calling a fax-machine
and the calling party is not a fax-machine also.
 
This situation is different for carrier ENUM.
Here a minimum set of required Enumservices needs to be
defined, depending on the intended usage of carrier ENUM
This intended usage needs to be defined first. The problem
here is the time-frame:
 
1. there is an immediate short-term need for carrier ENUM
to allow peering of carrier networks a. for additional
services currently not supported via conventianal
signalling (e.g. MMS), b. to allow additional peering
via IP-based technology for certain services between
carreir able to do so, c. to allow carriers to use
DNS-based technology for getting information required
for number portability (e.g. routing numbers).
 
These use cases need immediate solutions and implementations.
Since one cannot expect here that ALL assigned E.164 numbers
will be in Carrier ENUM at this time, and the PSTN as default
still exists, the basic questions
to be answered here are: what is the behaviour of a client
if no corresponding entry is found, and even more important:
what if an entry is found and the requested service is not
contained in the NAPTRs retrieved?
 
2. There is a mid-term need to provide IP-based peering
between 1. all networks using IP technology and then
eventually also 2. between PSTN-networks
 
3. The final solution will be that some time in the
future (I do not want now to discuss when, James;-)
the default PSTN interconnection will cease to exist
and ALL interconnections (peerings) will be IP-based.
Latest at this time all E.164 numbers must be in ENUM
and also a complete set of Enumservices must be available
covering all required services. 
 
Side remark: sometimes between step 2 and 3 the basic
addressing (naming) scheme used for routing between IP-based 
networks needs to be defined, and this IMHO cannot be E.164
based, it will be domain based. So E.164 numbering will
change from the main naming scheme to an additional 
naming scheme. 
 
As a result, issues like "number portability" and 
routing numbers will go away. NP will be a simple
change in database and routing numbers will not be
needed at all.
 
Resumee:
 
Requirements for Infrastructure ENUM need to
define which Enumservices are required for
short-term step 1 immediately, because
the second step will take some time.
In a second step it is necessary first to
define the requirements for "VoIP" peering
(I have a problem with VoIP here) and 
derived from this the final set of 
Enumservices required.

I will try to give some additional comments
regarding this issue in reply to
draft-livingood-shockey-enum-npd-00.txt
 
Richard Stastny

 

 
Steve