[Enum] IETF, ENUM and NGN

["Stastny Richard" <Richard.Stastny at oefeg.at>]

James McEachern [mailto:jmce at nortelnetworks.com] wrote:

> I also am unsure what the concept of a "long distance carrier" would mean
> in
> the context of the end-to-end model, and in a universe where Session
> Border
> Controllers, NAT's B2BUAs and other evils do not exist.
> 

[Richard>] Still having my headache from yesterdays e-mails on this
list, I think James remark is up to the point

I wasn't sure if I am really on an IETF mailing list, it
sounds more like ETSI TISPAN or 3GPP.

May I throw in some buzzwords reminding you where we are:

The Internet and it's success stands for

Keep it simple, stupid
Stupid network
End-to-end connectivity
End-user control
Vertical layering
VoIP is a SW application and a product
etc.

and NGN stands for:

Intelligent network
Walled garden
Horizontal stove pipes
Firewalls
Session Border Controller
Managed networks
VPNs?
Points of Interconnect
Termination charges
Transit networks = long distance carriers
Voice is a service
Provider control
etc.


I also want to remind everybody on the position of the FCC 
regarding VoIP:

However, all participants in the broadband value chain should embrace a set of connectivity principles which ensure that consumers:
-Can gain access to any content on the internet
-Can run the applications they choose
-Have adequate information regarding their service capabilities
-Can attach any devices to their broadband connection that do not harm the network

We should also not forget that the basic routing mechanism for connectivity
on the Internet is the DNS and URI, so for VoIP this are sip and h323 URIs

ENUM is only an add on and not basically necessary to route calls.
Since URIs are used as address-of-record and contact-address, they are
intended to be used to identify the terminating server and terminal and
are NOT intended to be used for routing via transit "networks"
Therefore ENUM should not be used for this purpose for two reasons:
1. ENUM is not designed for this and lacking the required information
2. it is contradicting the end-to-end philosophy of the Internet.

If NGN proponents are trying to set up mechanism on IP to allow
routing of E.164 numbers and also to transfer the complicated routing
regime they have between "networks" and also the IN NP databases,
they may do so, even they may use ENUM technology. And it
is perfectly valid for ETSI and 3GPP dealing with these issues

But we should be well aware of the complexity of the issue, and
Maybe we should also give them a warning or tutorial that there
Is no such thing as "networks" on the Internet.

The Internet is only one network and therefore things could (and
will be) implemented in a much simpler way.

Summary: The basic mechanism for end-to-end connectivity for
IP Communications including VoIP on the Internet is URIs.

The usage of ENUM is an optional add-on.

Important note: The model of end-user control seems to be
flawed, at least for residential customers. Same holds
true for the original idea for using ENUM as "business card"
replacement. There seems to be no market for this, at least not
at the moment. So one way forward could be to shift the
control of the domain (at least for certain number ranges)
to the entity providing the SIP service (either provider or enterprise)

Second important note: this does NOT compromise the end-to-end
connectivity model!! 
and also NOT the opt-in model, only that in this case the provider
is opting-in on behalf of his customer.

Joe Doe customers just do not want to fiddle around with ENUM-entries,
they simply do not understand ENUM. (read my lips, not only Joe Does ;-)


If the PSTN is moving to IP and therefore seeking for a routing
mechanism for E.164 numbers on IP, this may be the DNS, but maybe
be not (as Rich said). If the decide to use ENUM-technolgy, ok,
but this will be very complex (as everything on the PSTN is),
it will be not optional (it cannot be), and it will therefore
be orthogonal and independent from (User) ENUM.

This also implies that this CANNOT happen in the same tree, because
ownership, administration and delegation path are completely 
different.

Richard

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum