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

From: "Pfautz, Penn L, ALABS" <[email-masked]>
Date: Fri, 09 Jul 2004 16:13:32 -0400

For those not on i-d announce...
-----Original Message-----
From: i-d-announce-bounces at ietf.org [mailto:i-d-announce-bounces at ietf.org] On Behalf Of Internet-Drafts at ietf.org
Sent: Friday, July 09, 2004 11:28 AM
To: i-d-announce at ietf.org
Subject: I-D ACTION:draft-pfautz-lind-enum-carrier-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: A Combined User/Carrier ENUM
	Author(s)	: P. Pfautz, S. Lind
	Filename	: draft-pfautz-lind-enum-carrier-00.txt
	Pages		: 5
	Date		: 2004-7-8
	
This document considers how so-called "carrier" or 
     "infrastructure" ENUM and "end user" or "public" ENUM can share a 
     single Tier 1 registry yet have independent Tier 2 providers. This 
     approach allows the common cooperative infrastructure required by 
     ENUM to be shared by end users and carriers reducing costs and 
     facilitating adoption of ENUM generally. The essence of the 
     proposal is to populate the Tier 1 registry with non-terminal 
     NAPTRs rather than NS records and use different ENUM service 
     fields for carrier and end user records.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-pfautz-lind-enum-carrier-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv at ietf.org.
In the body type:
	"FILE /internet-drafts/draft-pfautz-lind-enum-carrier-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

---

From: Michael Haberler <[email-masked]>
Date: Sat, 10 Jul 2004 13:23:31 -0400

Penn, Steve,
that is an interesting idea. However, I doubt wether it solves the problem 
which I believe hinders adoption and was the reason for the infrastructure 
ENUM discussion in the first place.

It seems to me the main reason why ITSP's are pushing for a *non* e164.arpa 
tree solution is that with the current thinking behind user ENUM, namely 
user opt-in, and in particular beforehand government opt-in will result in 
an extremely slow overall adoption curve, and consequently ridiculously low 
resolution rates for a long time to come.

Bypassing the adoption of user opt-in is half the story if you're still 
supposed to hold E2C entries in a national subtree of e164.arpa - because 
basically all 184+ governments are still asleep at the switch (give and 
take some). And that isnt going to change soon.

If the underlying problem is the growth speed of the e164.arpa tree at the 
national level, it doesnt help in terms of footprint to decorate the 
occasional subtree therunder with a different type of attribute since the 
problem a level up remains unaddressed.

WRT the user opt-in idea, I can assure you my experience that as soon as an 
operator decides to support user ENUM it will very much look like operator 
opt-in in the first place - for the simple reasons they will have to 
support it, and it cannot, at this point in time, sold as a per-user 
service attribute to the general public. The first thing which happens is a 
change in ITSP terms&conditions that users "agree to opt-in", which IMO is 
the only viable option to start with.

What I'm saying is - if you have public ENUM with any reasonable stab at 
market share with the VoIP operators, the need for a dual-mode solution 
diminishes fast - the only reason left is "controlled peering".

If you dont have public ENUM, your proposal wont help too much because it 
assumes a cc Tier1 delegation in the first place.

Unfortunately it doesnt help if one is part of the "lucky ones" because I'm 
coming to believe that the winning strategy still is the one which gets 
coverage fastest. Given governments in the loop, it's hard to see how this 
can be anything in e164.arpa.

-Michael
At 21:39 09.07.2004, Pfautz, Penn L, ALABS wrote:
For those not on i-d announce...
-----Original Message-----
From: i-d-announce-bounces at ietf.org [mailto:i-d-announce-bounces at ietf.org] 
On Behalf Of Internet-Drafts at ietf.org
Sent: Friday, July 09, 2004 11:28 AM
To: i-d-announce at ietf.org
Subject: I-D ACTION:draft-pfautz-lind-enum-carrier-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

---

From: Jim Reid <[email-masked]>
Date: Sat, 10 Jul 2004 14:41:41 -0400

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

---

From: Jeff Williams <[email-masked]>
Date: Sat, 10 Jul 2004 20:40:27 -0400

Michael and all,

  Opt-out provisions for User-Enum must be made available as part of the
standards track.  It is not currently for reasons that have been made
obvious on this forum which are rooted in Anti-privacy bigots driving
the standards track.  If such political ideology based standards tracks
continue within the IETF, let alone ENUM, not only will exceptance
be hard to come by, legal actions will proliferate and an alarming rate.

Michael Haberler wrote:

>   ------------------------------------------------------------------------
>
>    Part 1.2       Type: Plain Text (text/plain)
>               Encoding: 7bit

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1 at ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827

---

From: Marian Durkovic <[email-masked]>
Date: Sun, 11 Jul 2004 04:31:49 -0400

On Sat, Jul 10, 2004 at 07:35:47PM +0100, Jim Reid wrote:
> Could somebody *please* tell me what they can

As I wrote before, access to _both_ public and private tree at the same time.

> infrastructure.  It all just works.

No, it doesn't. By establishing private instance of e164.arpa all data
in public e164.arpa is lost. Suppose the company you mention has internal
preference to:

A) query public ENUM tree and use it if record present
B) route all calls for +1234... towards telcoa.com
C) route all calls for +4212... towards tecomb.com
......
Z) fallback to PSTN for anything else

To ensure B), C) and possibly more, the company needs to establish 
infrastructure ENUM tree. If it places those records into private
e164.arpa like this: 

*.4.3.2.1.e164.arpa.  pointing to telcoa.com
*.2.1.2.4.e164.arpa.  pointing to telcob.com
.....

this private e164.arpa overlays the public e164.arpa., information in it is 
lost and there's no way to take care of step A).

	With kind regards,

		M.

--------------------------------------------------------------------------
----                                                                  ----
----   Marian Durkovic                       network  manager         ----
----                                                                  ----
----   Slovak Technical University           Tel: +421 2 524 51 301   ----
----   Computer Centre, Nam. Slobody 17      Fax: +421 2 524 94 351   ----
----   812 43 Bratislava, Slovak Republic    E-mail/sip: md at bts.sk    ----
----                                                                  ----
--------------------------------------------------------------------------

---

From: Richard Shockey <[email-masked]>
Date: Sun, 11 Jul 2004 17:07:22 -0400

At 10:26 PM 7/10/2004, you wrote:
Michael and all,
  Opt-out provisions for User-Enum must be made available as part of the
standards track.  It is not currently for reasons that have been made
obvious on this forum which are rooted in Anti-privacy bigots driving
the standards track.

Watch it you are starting to cross the line here. This is your first 
warning. The chairs will not tolerate the discussion degenerating into 
flatulent name calling.

Opt-Out provisions like all administrative issues within the e164.arpa tree 
are nation state issues  associated with their portions of the E.164 plan. 
Take your complaint to the ITU.

 If such political ideology based standards tracks
continue within the IETF, let alone ENUM, not only will exceptance
be hard to come by, legal actions will proliferate and an alarming rate.
Michael Haberler wrote:
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jeff Williams <[email-masked]>
Date: Mon, 12 Jul 2004 01:41:16 -0400

Richard and all,

  No the opt-out with respect to privacy is a common practice in many
areas of many industries and a defacto-standard in quite a few of them
such a listing phone numbers, which has already been discussed and
recognized on this forum, as well as in the financial credit industry.  Hence
your quip below appears to be more akin to a errant remark referencing
the ITU.  Hence any IETF standards track that seeks to disconnect
pricacy/security from good common existing practice at the expense
of stakeholders/users is at least not appropriate, but also irresponsible.

Regards,