Subject: RE: [Enum] .TEL and ENUM?

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 23 Mar 2004 15:19:37 -0500

You should check out Jeff Pulver's personal blog on this item today:
http://192.246.69.231/jeff/personal/archives/000654.html

Jason

> >>>>> "Tim" == Tim Ruiz <[email-masked]> writes:
> 
>     Tim> http://www.icann.org/announcements/announcement-19mar04.htm
> 
>     Tim> I found the .MOBI and .TEL applications of particular
>     Tim> interest, especially the .TEL application from pulver.com:
> 
>     Tim> http://www.icann.org/tlds/stld-apps-19mar04/tel-pulver.htm
> 
>     Tim> I was wondering if you have had a chance to look at that. It
>     Tim> appears to my less qualified eye that it would conflict with
>     Tim> ENUM.  Is my reading of it correct?

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

---

From: Jim Reid <[email-masked]>
Date: Tue, 23 Mar 2004 20:51:11 +0000

>>>>> "Jason" == Livingood, Jason <[email-masked]> writes:

    Jason> You should check out Jeff Pulver's personal blog on this
    Jason> item today:
    Jason> http://192.246.69.231/jeff/personal/archives/000654.html

Thanks for the URL. However this says nothing new. It confirms he
either doesn't know or care about the many difficult issues of
sovereignty and national interests that apply to the use of E.164
numbers. I don't know whether this makes him a madman or a genius. :-)

BTW his reference to "multiple implementations of ENUM" is a nonsense.
When E.164 numbers are mapped into domain names, this can only be
called ENUM if the protocol that's used complies with RFC2916(bis). So
if the mapping is done under e164.arpa, it's ENUM. If it's somewhere
else, it can't be ENUM.

---

From: Richard Shockey <[email-masked]>
Date: Tue, 23 Mar 2004 16:26:56 -0500

>if the mapping is done under e164.arpa, it's ENUM. If it's somewhere

Well that maybe stretching the semantics a bit  .. there are folks that 
want to use the technology of ENUM for all sorts of private telephony 
signalling purposes and many of them are operators and the tree of 
resolution is not and will not be in e164.arpa. The discussions over 
Operator ENUM have been going on for years NetNumber et al have had 
services available and that's just great. Its just I don't think a private 
product offering needs an endorsement by ICANN.

2916bis is fundamentally about trust and preserving the integrity of the 
ITU E.164 numbering plan and the administrative rights and privileges 
accorded nation states under that plan.

It might be worth noting that the E.164 plan helped make the global PSTN 
possible. Trust in both the E.164 plan and the admistrative procedures 
surrounding the implementation of RFC 2916bis is essential if we want to 
roll out global VoIP and other services. Trust in a global system that all 
service providers, world wide, can rely upon.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:[email-masked]
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>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: "Christian de Larrinaga" <[email-masked]>
Date: Tue, 23 Mar 2004 22:59:31 -0000

well surely e164 numbers is just one numbering plan implementable using ENUM
rather than the only one?

Christian

> >>>>> "Jason" == Livingood, Jason
> <[email-masked]> writes:
>

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 24 Mar 2004 00:32:08 +0100

Indeed, ENUM may work under any TLD. But creating a paralel root  to 
e164.arpa. is not the answer for the current issues we have with it.

Adrian

---

From: Ray Anderson <[email-masked]>
Date: Tue, 23 Mar 2004 23:30:55 +0000

Its the "difficult stuff" around the technology that takes the time and 
requires the massive investment.

Thats why the "official" tree is the one that will get support and which 
will have great value.  I'm sure
there will be some oddball private namespaces like .tel might be able to 
become, but in the scheme of
things they will be niche and not worth much attention.

UMTS 's big value is in the "U" - not in the protocols or spectrum.  Thats 
what made it hard, and
makes it last for tens of years.   Just as the "M" in GSM made it the place 
to be.

For what its worth, Bango is totally committed to using ENUM to determine 
the real "home/owner" for
phone numbers because its the best chance we have.

At 21:26 23/03/2004, Richard Shockey wrote:

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Mar 2004 00:19:56 +0000

>>>>> "Christian" == Christian de Larrinaga <[email-masked]> writes:

    Christian> well surely e164 numbers is just one numbering plan
    Christian> implementable using ENUM rather than the only one?

ENUM is defined in RFC2916(bis). This maps E.164 numbers into domain
names under e164.arpa. E.164 numbers could be, and indeed are, mapped
into domain names anywhere in the DNS. And, in principle, any numbering
scheme could be mapped into domain names under e164.arpa. But neither
of these should be called ENUM. They might be ENUM-like, but they're
not ENUM as it's understood by RFC2916(bis). What's also in this RFC
is a role for ITU in the delegation process for country codes. This
implicitly safeguards national interests and the sovereignty issues
surrounding national resources: a country's E.164 numbers. AFAIK no
other "ENUM-like" mapping scheme for E.164 numbers provides those
essential safeguards.

---

From: Richard Shockey <[email-masked]>
Date: Tue, 23 Mar 2004 19:14:09 -0500

>rather than the only one?

Well funny you mention other numbering plans .. if you look a the global 
plan for the next generation barcode technology.. aka EPCglobal using RFID 
the methodology for resolving the EPC code into the Object Name Service 
looks a lot like ENUM ( for some odd reason :-)) but again in a different 
domain.

http://www.epcglobalinc.org/standards_technology/Secure/v1.0/WD-ons-1.0-20030930.pdf

I'd go so far to say that enterprise private dialing plans can be easily 
implemented within their own domains using the DNS and the technology 
outlined in 2916 and for any number of reasons makes a great deal of sense. 
Great way to force interoperability among diverse SIP based IP PBX's.

---

From: Richard Shockey <[email-masked]>
Date: Tue, 23 Mar 2004 19:17:09 -0500

At 06:30 PM 3/23/2004, Ray Anderson wrote:

>will have great value.  I'm sure there will be some oddball private 
>namespaces like .tel might be able to become, but in the scheme of things 
>they will be niche and not worth much attention.

We've noticed alternative roots  havent gone very far either ..including 
that New.NET thing or whatever it was called.

>makes it last for tens of years.   Just as the "M" in GSM made it the 
>place to be.
>
>the real "home/owner" for phone numbers because its the best chance we have.

well said and thanks for the support some of us are working on 1. as fast 
as we can..

---

From: Jeff Williams <[email-masked]>
Date: Tue, 23 Mar 2004 22:30:39 -0800

Jim and all,

> numbers. I don't know whether this makes him a madman or a genius. :-)

  I would have to agree here...

> if the mapping is done under e164.arpa, it's ENUM. If it's somewhere

  Of course RFC2916(bis) is flawed as I some time ago pointed out,
as it is too restrictive in general..  But I have already gone over all that
some time ago.  Hence leaving your last statement here invalid..
Therefor many different and "multiple implementations of ENUM"
will be done and will have various levels of success or failure...

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 [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

---

From: Jeff Williams <[email-masked]>
Date: Tue, 23 Mar 2004 22:37:26 -0800

Richard and all,

> product offering needs an endorsement by ICANN.

 Any endorsement from ICANN at this juncture is circumspect at best...

> accorded nation states under that plan.

  I seriously question this as have many of the nation states governments
have begun to question it as well...

> possible.

  Yes helped.

> Trust in both the E.164 plan and the admistrative procedures
> roll out global VoIP and other services.

RFC 2916bis is not essential and in some instances or for some
countries not advisable...

> Trust in a global system that all

Good point if such a system is ever developed...

Regards,

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 24 Mar 2004 07:37:07 +0100

> if the mapping is done under e164.arpa, it's ENUM. If it's somewhere

Yes, but...even if we are not that precise on the use of the word ENUM 
(I think you are right Jim, but...) we have problems.

The issue is that the calling party have to know, given only the E.164 
number is known, what domain name to add to the domain part which is 
created by the numbers.

If I happen to have the E.164 for Jeff, how do I know whether I should 
look up things in tel and not in e164.arpa and vice versa?

The whole idea with ENUM builds on the idea that the domain name is one 
and only one, except in closed areas (like inside an enterprise) where 
everyone agrees on use of something else. That is though as Jim says 
not ENUM, but "ENUM-like service" or "service using ENUM technology" or 
whatever.

So, IF tel is created, I only see a "war" in the market where either 
e164.arpa or tel "wins".

There can only be one...

And you all know what _I_ want.

     paf

---

From: "Christian de Larrinaga" <[email-masked]>
Date: Wed, 24 Mar 2004 09:57:59 -0000

> Patrik Faltstrom  wrote 24 March 2004 06:37

> look up things in tel and not in e164.arpa and vice versa?

If I've read what Jeff proposes right he is suggesting is that .tel will be
used only by operators (so users of those operators will just dial or push
to talk or whatever) and the .tel service will default to e164.arpa if the
record for that number exists in e164.arpa. (I haven't seen a technical
appraisal that sets out how they propose to achieve this)

Christian

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 24 Mar 2004 11:02:37 +0100

> appraisal that sets out how they propose to achieve this)

They can already to that in tel.pulver.com. A new TLD is not needed.

    paf

---

From: "Christian de Larrinaga" <[email-masked]>
Date: Wed, 24 Mar 2004 11:06:37 -0000

> From: Patrik Faltstrom [mailto:[email-masked]]
> Sent: 24 March 2004 10:03
>
>

Yes that is exactly what I suggested to Jeff :-).

I am not a part of Jeff's bid and so not an apologist for him but I think
there is an interesting inference here that is worth exploring.

First a big IF

IF

Pulver's .tel idea will reliably defer first to the official e164 root
(where it exists) AND is private ENUM (or ENUM like!) for operator use only

THEN

we can ask the question

Is it better to have an appraised and openly available service for operators
only that is approved and under the authority of ICANN communities than
leave the space completely wild to just any.enumlike.com as is the situation
today?

If so then applying for an SLD begins to look public spirited! As only by
applying for an SLD at ICANN can one achieve that level of public oversight
over an ENUM (like!) application by operators that defers reliably to the
delegated national authorities.

Christian

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Mar 2004 11:15:27 +0000

>>>>> "Christian" == Christian de Larrinaga <[email-masked]> writes:

    Christian> If I've read what Jeff proposes right he is suggesting
    Christian> is that .tel will be used only by operators (so users
    Christian> of those operators will just dial or push to talk or
    Christian> whatever) and the .tel service will default to
    Christian> e164.arpa if the record for that number exists in
    Christian> e164.arpa.

This may be true, but it's pointless and irrelevant. It's not a
justification for a new TLD. If operators want to put phone numbers
into some mutually agreed part of the DNS, they can do that
already. [Some will have doing this for a while.] All they need to do
is agree where the tree goes in the DNS and make sure it's not
public. A telco might need to lookup my unlisted number to route calls
to me. But that data must not be in the public DNS for obvious
reasons.

If telcos need to decide on a mutually agreed domain name for this,
they can do this through various industry bodies like ETSI or ITU.
It doesn't need a new TLD. Or any other domain name for that matter.
That's why we have e164.arpa.

Oh and if Jeff is saying e164.arpa will be preferred over .tel
entries, what's the point of ever populating .tel? This would be as
stupid as creating a .kom TLD and then saying this only gets used if
the name isn't already in .com.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 24 Mar 2004 12:49:37 +0100

They can already to that in tel.pulver.com. A new TLD is not
    needed.

Apart from that, note that the other .tel bid excludes ENUM-style
use.

If I recall correctly, with the previous bunch of new TLDs, ICANN
decided that if there were multiple bids for the same name, the
parties should make a combined bid. They refused to choose. (Or
maybe this was just the position of some board members). Something
like that might happen again.

Note that the comment periode start the 1st of April (no joke). It
might be better to comment to ICANN directly then on this list.

	jaap

---

From: Jim Reid <[email-masked]>
Date: Wed, 24 Mar 2004 11:53:44 +0000

>>>>> "Christian" == Christian de Larrinaga <[email-masked]> writes:

    Christian> Is it better to have an appraised and openly available
    Christian> service for operators only that is approved and under
    Christian> the authority of ICANN communities than leave the space
    Christian> completely wild to just any.enumlike.com as is the
    Christian> situation today?

This question doesn't follow from your hypotheticals. There is no role
for ICANN in ENUM. End of story. All ICANN have to do is oversee a
single consistent name space in the DNS which provides a platform for
ENUM and many other things.

If telcos want to have a private name space for whatever purpose they
like, that is up to them. Many enterprises do this already: internal
root servers on the corporate intranet. The telco operators can get
together and decide that name space for themselves, just like the
3G/GSM people have done with the bogus .gprs TLD. An ICANN-endorsed
TLD isn't needed. The telcos could arrange an industry standard for
operator ENUM though something like an ITU recommendation or an ETSI
standard. [ETSI is working on such a standard.] No doubt there are
other fora where internal telco conventions and standards get agreed.

Dragging ICANN into this arena may well turn out to be spectacularly
counter-productive. Imagine how say China will react if ICANN approves
.tel and Jeff starts entering Chinese E.164 numbers there without the
approval of the Chinese authorities. Repeat this for any other country
of your choosing. For bonus points, pick a country that's very
sensitive about the perception that the internet and ICANN is under
the control of the US government.

I fail to see how Jeff's .tel differs from any.enumlike.com, even if
.tel did exist with ICANN's blessing.

---

From: Richard Shockey <[email-masked]>
Date: Wed, 24 Mar 2004 09:00:27 -0500

>might be better to comment to ICANN directly then on this list.

Thank you Japp ... a excellent suggestion to all.

---

From: Jeff Williams <[email-masked]>
Date: Wed, 24 Mar 2004 17:24:21 -0800

Jim and all,

  I agree there is no good reason for .TEL or for that matter
a .xxx TLD.  However there is perhaps a desire for these
TLD's. Given that there such a desire, not allowing for their
inclusion/creation based on "Good reason" may not be
enough...

Regards,

---

From: Jeff Williams <[email-masked]>
Date: Wed, 24 Mar 2004 17:38:23 -0800

Jaap and all,

  Commenting to ICANN directly might help but I doubt it..
The two bids for .TEL are two different views of the confidence
in the direction the IETF has taken with ENUM, admitted or
not...

Regards,

---

From: Irwin Lazar <[email-masked]>
Date: Wed, 24 Mar 2004 22:25:02 -0500

> From: Jeff Williams <[email-masked]>
> Date: Wed, 24 Mar 2004 17:24:21 -0800
> To: Jim Reid <[email-masked]>
> Cc: Christian de Larrinaga <[email-masked]>, Patrik Faltstrom
> <[email-masked]>, Tim Ruiz <[email-masked]>, Richard Shockey
> <[email-masked]>, [email-masked]
> Subject: Re: [Enum] .TEL and ENUM?
> 
> Jim and all,
> 
What about the idea that I could use "[email-masked]" for my phone number?
It seems to me that the .tel TLD would be an ideal marker for consumer phone
and would easily differentiate to the average person that they were
referring to my phone instead of my e-mail account.

irwin

---

From: Jeff Williams <[email-masked]>
Date: Wed, 24 Mar 2004 22:51:03 -0800

Irwin and all,

> referring to my phone instead of my e-mail account.

  Sorry to burst your bubble here, but the "@" tells me it is an Email
address only..  < shrug >  Using a TLD or in this instance a "Class
of TLD, ergo an sTLD" for a marker can be helpful in some instances
for a class of goods or services.  But .TEL is a type of communication
service, not a class.  Hence in many instances domain names in the
.TEL name space could be very misleading...  Your example is only
one such instance...

Regards,