Subject: [Enum] ENUM Service Providers

From: Vijaya Venkatachalam <[email-masked]>
Date: Mon, 13 Aug 2001 17:17:27 -0400

Hi,

I was wondering if there were any ENUM service
providers out there?

Thanks,
Vijaya

---

From: "Chris John" <[email-masked]>
Date: Tue, 14 Aug 2001 03:17:09 -0400

Vijaya,

NetNumber is a commercial ENUM Service Provider.  We can be reached at
www.netnumber.com .

Sincerely,

Chris John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Vijaya Venkatachalam
Sent: Monday, August 13, 2001 5:17 PM
To: [email-masked]
Subject: [Enum] ENUM Service Providers

Hi,

Thanks,
Vijaya

_______________________________________________
enum mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/enum

---

From: Chip Sharp <[email-masked]>
Date: Tue, 14 Aug 2001 08:09:17 -0400

As far as I know, no companies are offering the ability to enter NAPTR RRs 
into DNS corresponding to a name derived from an E.164 number in the 
e164.arpa domain as defined in RFC2916.

There are some organizations offering services based in part on procedures 
defined in RFC2916.  However, they do not use the e164.arpa domain as 
defined in RFC2916.

Chip

---

From: "A.M.Rutkowski" <[email-masked]>
Date: Tue, 14 Aug 2001 08:58:11 -0400

Hi Chip,

>defined in RFC2916.  However, they do not use the e164.arpa domain as 

ENUM is a protocol for mapping telephone numbers - most
popularly represented in DNS using the Rose-Malamud algorithm -
to other identifiers or service capabilities associated with
that number.  RFC2916 is simply one rather controversial Proposed
Standard for doing this.

ENUM can and will be effected using multiple DNS RR types -
CNAME, DNAME, A, NAPTR, and especially SVR, as well as supported
by PTR RRs.  You might want to reference ENUM working group
discussions on this topic such as Lucent's Greg Vaudreuil,
Microsoft's Christian Huitema, NetNumber's David Peek, or
Telcordia's Hong Liu.  See ENUM archives at
http://www.ngi.org/enum/pub/Other_RRs.txt  Indeed, with all
the PAM related developments underway, SVR RRs seem the
clear winner.  They should also afford significantly greater
potential end user privacy.

It's worth noting that NetNumber was a major pioneer in the
field, and the first to offer commercial ENUM services in the
marketplace within the domain e164.com that should intrinsically
dramatically outperform anything in e164.arpa

Any general principle documents going forward to the ITU or
any other intergovernmental body should emphasize as a *first
principle*, not adversely affecting NetNumber and other
commercial ENUM services in the marketplace.

--tony

---

From: Jim Reid <[email-masked]>
Date: Tue, 14 Aug 2001 07:20:14 -0700

>>>>> "Tony" == A M Rutkowski <[email-masked]> writes:

    Tony> It's worth noting that NetNumber was a major pioneer in the
    Tony> field, and the first to offer commercial ENUM services in
    Tony> the marketplace within the domain e164.com that should
    Tony> intrinsically dramatically outperform anything in e164.arpa

I'm very curious how one domain name "intrinsically dramatically
outperforms" another. Please explain. Sure, a name server could be
faster than another or appear to be faster because it's sited close to
a good exchange point. But how does a name outperform another name?
It's only a name after all.

A cursory check with dig shows that there are two name servers for
e164.com. These both appear to live on the same subnet. [After the
Microsoft debacle a few months ago, I would have thought nobody made
basic DNS administration mistakes like that any more.] Those two name
servers give inconsistent answers for the zone's NS records. They also
return referrals to non-existent hostnames like ns3.e164.com and
ns4.e164.com. The two name servers for e164.com say they are running
BIND 9.1.0. This contains bugs that have been fixed in the current
BIND9 version, 9.1.3, which has long superseded it.

By contrast there are currently three name servers for e164.arpa.
These are in different locations on different nets and are operated by
different organisations. They all answer consistently. So aside from
this domain apparently being endorsed by the ITU and IAB -- the key
movers and shakers in ENUM -- its DNS infrastructure appears to be in a
much healthier state that e164.com.

---

From: Chip Sharp <[email-masked]>
Date: Tue, 14 Aug 2001 10:39:17 -0400

Note that I didn't use the term "enum" or "ENUM" in my response.

enum is the name of the working group in IETF that produced RFC2916.  I'm 
not sure what "ENUM" means anymore.

Chip

At 08:58 AM 8/14/2001, A.M.Rutkowski wrote:
>Hi Chip,
>
>>As far as I know, no companies are offering the ability to enter NAPTR 
>>RRs into DNS corresponding to a name derived from an E.164 number in the 
>>There are some organizations offering services based in part on 
>>procedures defined in RFC2916.  However, they do not use the e164.arpa 
>>domain as defined in RFC2916.
>

---

From: "A.M. Rutkowski" <[email-masked]>
Date: Tue, 14 Aug 2001 12:24:09 -0400

Hi Jim,

>It's only a name after all.

On one side, we have a commercial competitive global
name resolution infrastructure operated and optimized
by a provider who is free to chose sites, machines,
architectures, resource records types, administrative schema,
etc., to minimize latencies, optimize resolution, and
enhance robustness.

On the other side we have something that's a cross between
the U.N. and the Soviet PTT sliced and diced on three different
planes with nearly all the parties incented to kill it, and
using a schema that few if any users will want.

After someone tries to resolve a number and gets nothing
for 9,999 out of 10,000 numbers; and that one takes 60
seconds to resolve to some ambiguous set of URLs, they'll
catch on.

>much healthier state that e164.com.

IMHO, the key movers and shakers in ENUM are the customers.

--tony

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Aug 2001 15:06:55 -0700

>that number.  RFC2916 is simply one rather controversial Proposed

Oh?  Please point to other standards for doing this, in particular ones 
that use the name "ENUM".  (As already noted, one could have sworn that, in 
fact, ENUM was the name of an IETF working group...)

And as we have discussed before, there is no controversy about the ENUM 
specification, except the controversy you keep trying to introduce.  (Why 
Tony would think that this is some sort of Macbethian cauldron he can stir 
is mystifying.)

>Telcordia's Hong Liu.

Yes, you might.  You will then see that Tony is continuing to confuse 
technical debate with "controversy".  He seems unaware that technical 
debate is a natural part of the process of developing technical 
specifications, with little implication of future failure, success or 
controversy.  It is, in fact, downright impressive to see anyone trying to 
claim that the ENUM specification is controversial.

>dramatically outperform anything in e164.arpa

I hope we are all duly impressed by this forceful, yet content-free, 
assertion.

Note that no clarification has been forthcoming from Tony, in spite of a 
request that he explain what this nonsense is supposed to mean.

As to the question of "competitive" telephone number lookup services, Tony 
is continuing to confuse "white pages" like services with "yellow pages" 
like services.  By that I mean services that are formally tied to the 
assignee of a telephone number, versus those that have no such formal 
association.

The e164.arpa ENUM effort is administratively interesting because it MUST 
ensure that the DNS-based use of a telephone number is ONLY associated with 
the registrant who is assigned that telephone number for telephony 
purposes.  All those other "competitive" services that Tony likes to hype 
will offer no such assurances.  Hence, the agency associated with a phone 
number in one of those other services well might be different that is 
associated with the the number used for telephony.

d/

At 01:24 AM 8/14/2001, A.M. Rutkowski wrote:
>>outperforms" another.
>...

1.  Note that there is no technical content to Tony's statement other than 
"the commercial effort will optimize placement of servers".  This is, of 
course, utter nonsense.

2.  Tony fails to discuss the problems created by having competitive 
efforts for an inherently hierarchical service.  Please see the RFC by the 
IAB or my own recent Internet-Draft that generalizes the IAB paper.

>seconds to resolve to some ambiguous set of URLs, they'll

ambiguity will be caused by implementing Tony's scheme, and no other way.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464