Subject: Re: [Enum] new I-D on carrier ENUM

From: "Peter Williams" <[email-masked]>
Date: Sat, 24 Jul 2004 13:00:55 -0400

The best motivation for infrastructure enum ( in private trees) Ive heared 
to date is that it enables the provider to satisfy the pending wiretap rules 
for VoIP - using established practice for assuring governments  of accuracy 
and reliability (and equipment companies get to sell carrier-grade voIP 
switches and provisioning/wiretap-capable systems). Not only is the 
reliability of the address of records problem contained within the 
provider's system and control, but the called party's providers record's 
accuracy can be similarly assured from the calling provider's perpective, 
when the infrastructure ENUM manages its own inter-provider naming tree 
links. Carriers will arrange interconnects only with parties with whom they 
have the required wiretap agreements and technical arrangements. (This is 
FBI wiretapping rules, note, not trunk spying by NSA, etc al.)

If the relability of the inter-provider knowledge links are managed by a 
third party - e.g. the public DNS, the provider can be punished for factors 
beyond the providers control. Ah, the entire population of iraq is suddently 
unreachable and their critical infrastructure stops working - becuase of a 
domain name dispute happening in a foreign court. Imagine the mess a third 
party could make to the wiretap arrangements, if such arrangements require 
accuracy in DNS records handled by third parties!

My understanding of the corporate business thinking about ENUM is that the 2 
main ENUM TTPs want the telcos to outsource such DNS management  - and thus 
pushing goverments for wiretap regulation , AND a regime of carrier 
sanctions - getting governments to create outsourcing markets for the 
assurance providers, essentially. This works well with the DARPA program for 
critical infrastructure generation, headed by .arpa. The FBI controls the 
telco via business regulation, and the DARPA controls the technical 
providers via IAB/ICANN. Im not sure where Vint stands, however: he stood on 
the political fence when these same issues were thrashing (between the very 
same agencies!) in the CA/certs world. We got an internet solution there, Im 
not sure what will happen with ENUM: telcos had the gumption to standup to 
the powers over mandatory key escrow then: Im not sure they have the will, 
this time, to even politic in their own business interests. May be cheaper 
to just outsource provisioning and name space management to the 
wiretap/escrow-capable TTPs.

From: Jim Reid <jim at rfc1035.com>
To: Michael Haberler <mah at eunet.at>
CC: enum at ietf.org, "Pfautz, Penn L, ALABS" <ppfautz at att.com>
Subject: Re: [Enum] new I-D on carrier ENUM Date: Sat, 10 Jul 2004 19:35:47 
+0100

>>>>> "Michael" == Michael Haberler <mah at eunet.at> writes:
    Michael> It seems to me the main reason why ITSP's are pushing for
    Michael> a *non* e164.arpa tree solution is that with the current
    Michael> thinking behind user ENUM, namely user opt-in, and in
    Michael> particular beforehand government opt-in will result in an
    Michael> extremely slow overall adoption curve, and consequently
    Michael> ridiculously low resolution rates for a long time to
    Michael> come.
Your perception may be right. But the rationale for a non e164.arpa
solution is wrong IMO. A domain name should not be confused with an
instantiaton of its name space on the public internet. It seems that
some people on this list are unaware of that distinction or are
choosing to ignore it. ITSPs -- whatever they are -- can perfectly set
up their own private instances of e164.arpa today and populate that
with whatever they want however they like. Provided that private tree
isn't visible on the internet and doesn't get confused with the public
e164.arpa tree, there's no problem. We're done. These ITSPs can just
do it. They don't have to ask anyone's permission. Or get a new TLD
from ICANN.
These ITSPs will presumably want a private tree anyway so they don't
disclose customer data or their network operations to competitors,
avoid privacy & data protection complications, get round restrictions
surrounding the use of the public tree, etc, etc. I simply cannot
understand what advantages there are to having a private tree under
some other to-be-agreed domain name that cannot be met by a private
tree under e164.arpa. Remember that's the domain name IETF has decided
gets used for ENUM. Could somebody *please* tell me what they can
achieve under this mythical private tree that they could not achieve
under a their own private e164.arpa tree?
In fact, choosing another domain name is fraught with complications.
Like choosing who will own and administer it. Or where that domain
name would sit in the DNS. [Hey, let's put this private tree under
JimsPrivateENUMTree.com and then watch the fun when I forget to renew
the domain name registration with Verisign.] Or what controls the
domain's owner would be able to apply and how they'd be policed.
BTW, I think that choosing another domain name for a private tree will
just add complexity and confusion, especially for applications. That
will also hamper the update of ENUM and flatten the adoption curve.
Somebody needs to state the glaringly obvious. Since nobody else has,
here goes. No matter where an application lives -- inside a telco's
net, on the public internet, in an intranet or extranet -- it must
only make exactly 1 DNS lookup of exactly 1 domain name to figure out
how a "call" gets routed. [That has to be the goal for ENUM, no matter
whether it's User ENUM or Infrastructure ENUM or Operator ENUM, however
these terms are understood.] After all, that's how the DNS works.
Now when the application makes that lookup, it doesn't necessarily go
to one set of name servers providing all three same name spaces. In a
telco's net, the application queries the telco's DNS infrastructure
which directs them to the telco's e164.arpa tree. On the internet, the
application would see the public tree for e164.arpa. And on a
corporate net, the application sees the company's private instance of
e164.arpa because it queries the company's internal DNS
infrastructure.  It all just works.
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

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