Subject: [Enum] A Modest Proposal

From: "James McEachern" <[email-masked]>
Date: Wed, 30 Jun 2004 15:22:26 -0400

Richard, 
In your excellent summary of ENUM you said that:

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

Considering this, and the circular debates of the last few weeks, I'm
starting to think that "our work here is done", and that continuing on to
consider Infrastructure ENUM is at best unnecessary, and a worst down right
harmful.  

Am I missing something?

James

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

---

From: [email-masked]
Date: Wed, 30 Jun 2004 18:08:48 -0400

Yes, the work may well be done.  Neither "Infrastructure ENUM" nor
"end-user ENUM" may need further IETF enum wg technical work.

However, it seems a shame that so many people on this list have
come to blanket conclusions about the need for multiple trees
without valid logic in their arguments.  Under certain circumstances,
if service providers REALLY need to do certain things in the DNS
in certain ways, then the arguments hold up.  But taking the leap
to the conclusion that infrastructure ENUM NAPTRs cannot peacefully
and easily coexist with other ENUM NAPTRs in a standard e164.arpa
tree seems to be self-serving.

The detailed rules for e164.arpa ENUM implementation will be determined
on a country code by country code basis.  This includes privacy/opt-in
aspects, and I expect that privacy will be given its proper weight.
Additionally, countries will realize that with very limited exceptions
E.164 numbers should only be assigned to/through service providers
who will ensure universal connectivity.  As a minimum, for example,
this means that no matter who holds an E.164 (public) number for voice
service, it should be technically dialable and reachable from any other
public voice service user, and vice versa.  (Of course, end users may
make use of optional services that could restrict the completion of
incoming calls based on various criteria.)

So:
1) If infrastructure NAPTRs are restricted to revealing only
number at provider.foo then privacy is maintained. I believe any arguments
to the contrary are unfounded.  I also believe that concerns on the
part of potential service providers about the need for secrecy regarding
which E.164 numbers they hold is overblown.  That information will be
readily available to other service providers through national numbering
resource administrators, portability databases, etc.
2) If individual numbers, not number blocks, are populated in
e164.arpa, then the concern about locating individual numbers in
contaminated blocks is a non-issue.  In some major country codes around
the world blocks won't even be a consideration.
3) If end users want to add NAPTRs for their own purposes, independent
of the infrastructure needs of the service provider that is the source
of their E.164 number, there are several ways to accommodate them --
none of which require gaming the nameservers.  One way is to put them
side by side with the infrastructure NAPTR.  It should be trivial for
client software to determine which NAPTR is appropriate for a given
purpose.
4) If a country wants to give end users more flexibility or control
over the nameserver where their "end-user" NAPTRs reside, the DNS
entry containing the infrastructure NAPTR could also be populated with
NS records pointing to the end user's nameserver of choice.  Again,
it should be trivial for client software to continue down the tree if
the infrastructure NAPTR isn't what it is looking for.

I believe the "public" ENUM under the single e164.arpa tree can
accommodate both service provider and end user needs without significant
administrative complexity.  Those who are unwilling to consider
implementing e164.arpa ENUM in such a way are free to try one or
another of the multi-tree, split DNS, etc. approaches that I believe
will ultimately prove unworkable for effective inter-carrier routing
and universal connectivity.  BUT, those who think they need to go down
those other paths should NOT claim that there cannot be a single-tree,
e164.arpa solution.

Can we talk about this during the enum wg session in August?

Jim

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