Subject: [Enum] What is "carrier ENUM"?

From: Patrik Fältström <[email-masked]>
Date: Tue, 05 Jul 2005 10:34:33 -0400

I think we have to take a step back and have a look at the  
requirements. Various people have listed their favorite requirements,  
and I thank you all for that. We have also seen many requirements in  
the documents made known to this wg.

But, to be able to move forward, I would like to have someone taking  
a step forward agreeing to be the writer of a "carrier enum  
requirements" document.

This doesn't have to be (but might be) as formal as one internet  
draft at the end of the day.

I just want to see all requirements being listed (or as many as we  
might come up with) WITHOUT discussing each one of them immediately.

So, please, can I get:
1) A person that agree on writing down the requirements
2) People sending requirements to this list, or the person when that  
person exists

3) People NOT arguing how stupid they think a requirement is before  
we open that discussion

Example of requirements might be (these are just examples):
1. Two VoIP providers want to do "VoIP peering" and to each other  
announce the E.164 numbers each have, and for each announce what  
ingress point the originating provider should use.

2. A carrier that think he is "responsible" for one E.164 number  
don't want to give up control over the DNS for the NAPTR for that  
number.

3. A carrier want to use ENUM, but the user(s) have not opt:ed in to  
the use of it.

It was the intention the first more look like a scenario than a  
requirement. This is why I want someone that have time to look and  
try to find what the actual requirements are...

    paf
Attachment:
PGP.sig
Description: This is a digitally signed message part
_______________________________________________
enum mailing list
enum at ietf.org

---

From: [email-masked]
Date: Tue, 05 Jul 2005 11:57:36 -0400

Hello, 

I think we should have a same understanding about user ENUM and carrier ENUM.

In JAPAN ENUM Study Group, we discussed about User ENUM and
Operator(=Carrier) ENUM. We could not reach one conclusion.
Then, we compared this two approach and we made a report.

Please check our report and comment to us.

       http://www.nic.ad.jp/en/enum/ENUMReport.pdf

  at 30-38 pages.

I'm happy if this report helps mutual understanding.

In my opinion, User ENUM and Operator ENUM are too different and two
records cannot be in same domainname.

--
Fujiwara, Kazunori	JPRS

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

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 08 Jul 2005 05:12:29 -0400

Please dear wg participants.
Can we please list the requirements for various things, and not talk  
about conclusions, solutions etc?

We will NOT be able to move forward if you don't try to take a step  
back...

So, I don't want to see any more "Carrier ENUM is..." or "User ENUM  
is not..." or similar.

I want to see the requirements you were thinking of when you came to  
that conclusion.

Please...
    paf
On Jul 5, 2005, at 16:30, Patrik Fältström wrote:
I think we have to take a step back and have a look at the  
requirements. Various people have listed their favorite  
requirements, and I thank you all for that. We have also seen many  
requirements in the documents made known to this wg.

But, to be able to move forward, I would like to have someone  
taking a step forward agreeing to be the writer of a "carrier enum  
requirements" document.

So, please, can I get:
1) A person that agree on writing down the requirements
2) People sending requirements to this list, or the person when  
that person exists

3. A carrier want to use ENUM, but the user(s) have not opt:ed in  
to the use of it.

    paf

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 08 Jul 2005 10:37:35 -0400

The requirements you call for are ideological in nature. Whereas DNS has one
(remarkably effective) operating ideology, ENUM may have another. But many
acting in the tradition of the US portions of the Internet see ENUM as
necessarily deployed and operated in a manner similar to DNS. Others, with
the more traditional International perspectives used in the PSTN world, do
not.

This impasse cannot be solved by a technical requirement gathering process;
No IETF schism has ever been solved by such a process, which requires
political skills, in contrast. There are too many examples of technical
process being used to advance status quo political positions - a feature of
the US political scene.

As DNS is now an admitted arm of the US govt. national security policy
making, and a couple of IAB members act for that govt. in all but name, the
normal political process at IETF is either biased or fundamentally broken,
depending on your level of respect for our collective mission. As PSTN
politics is necessarily international in nature, and we are attempting to
address Internet/PSTN convergence, ENUM requires some accommodation to the
international way in which cooperative telco rules are hashed out. The act
of denying this (on technical pretexts) is causing the friction, and the
fueling the impasse.

When we faced this kind of impasse in the early 1990 in the PKI area, when
the positions of US govt + IAB + Internet Society + Rutkowski's personality
+ ITU-T's implosion + MIT patents + IETF technical WG documents + commercial
ambition combined ("in weird politics" VC) to make it impossible to deploy
public CAs for SSL etc in any IETF consensus manner, we had to leave IETF to
make the standards, for a while. Some very clever and shrewd politics by a
couple of Internet founders - who work created the international part of the
Internet - made it possible to come back in, once we broke the deployment
bottlenecks outside the organization. International powers were just NOT
having the US control the crypto infrastructure, per se, in that case;
something had to be done.

We can have a requirements gathering exercise if you want, in the ENUM case.
But unless req 1 is "each nationally-regulated telco deploying ENUM is 100%
independent of all foreign govt. policy making" then it?s a waste of time. 

Further convergence of Internet and PSTN culture in the IETF way of doing
things depends on the US relinquishing all control over the International
part of the Internet infrastructure. A corollary is that IAB and ICANN stop
being arms of the US govt, in all but name. Until these are structural
issues are solved, PSTN and Internet convergence will occur outside IETF
processes, I predict. Carrier ENUM will be a years long email thread, until
this happens.

> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of
> Patrik Fältström
> Sent: Friday, July 08, 2005 2:12 AM
> To: 'enum at ietf.org' ENUM
> Subject: Re: [Enum] What is "carrier ENUM"?
>