Subject: [Enum] My view of where we are in ENUM

From: Patrik Fältström <[email-masked]>
Date: Sun, 18 Mar 2007 15:23:50 +0100

Note: My co-chair have seen this, think the wording is correct, but  
these are my words

I identify regarding ENUM 4 different camps:

[A] User ENUM

The Public ENUM where the end user, holder of the E.164, is  
controlling the DNS and URIs.

[B] Public Infrastructure ENUM

ENUM that is in the public DNS, where lame delegation is not allowed,  
but the "carrier" responsible for the number (one and only one  
organisation, not the end user) is controlling the data in a way  
similar to A.

[C] Private Infrastructure ENUM

ENUM that is NOT in the public DNS, where groups of organisations on  
bilateral agreements can make information about the number public.  
Only parties signing up to the agreements can access the data in the  
DNS.

[D] Non-telephony users of ENUM

B (and possibly C - dependent on the agreements) treat "providers of  
telephony" special, using the regulative/legal definition of carrier  
as the special entity that part from the end user (as covered in  
solution A) can add data to the DNS. Category D include other  
providers of services, not the end user, that argue for them to get  
the same treatment as the carrier in solutions like B and/or C.

    ---- o -----

Out of these four, B is very vocal in the IETF. A participates, but  
is relatively silent (their problem is solved already). C is not  
participating in IETF but have their own conferences. D does not  
really exist, but I am nervous about the day when D get members, and  
what impact D might have on the solutions.

The solutions advocated for in the IETF related to B require a branch  
in the DNS tree, so that solutions for A and B are stored under  
different domain names, or apexes.

How that branch is created, where it is created, and whether it is to  
be created, is based on arguments that I personally feel we in the  
IETF are not capable of discussing. Especially as alternative C  
people are present in the discussions. Those discussions are such  
that I think (for example) ITU-T in SG2 should discuss.

What you should read of the note (that I stand behind that many of  
you objected to) is that I as co-chair tell IAB and IESG that I do  
not feel capable recommending the IETF to create a branch, or where  
some apex should be, of a specific kind without support from a  
combination of IAB and IESG. Plus a recommendation that many  
discussions that have been held in ENUM should be held outside of the  
IETF.

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

---

From: Andrew Newton <[email-masked]>
Date: Sun, 18 Mar 2007 14:19:55 -0400

On Mar 18, 2007, at 10:23 AM, Patrik Fältström wrote:
> ENUM that is NOT in the public DNS, where groups of organisations  
> on bilateral agreements can make information about the number  
> public. Only parties signing up to the agreements can access the  
> data in the DNS.

Actually, they could very well be in the public DNS but reside in  
private trees.

> C is not participating in IETF but have their own conferences.

That's not true, they just don't participate in the ENUM working  
group because their problem is already solved.

> How that branch is created, where it is created, and whether it is  
> to be created, is based on arguments that I personally feel we in  
> the IETF are not capable of discussing. Especially as alternative C  

I don't understand how C fits into your conclusion, but I suspect  
that you are right.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Sun, 18 Mar 2007 14:19:55 -0400

-andy

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Sun, 18 Mar 2007 16:52:42 -0400

Patrik:
I would tend to agree with your parsing of the different varieties of ENUM with the possible exception of D.
The real world and its regulatory framework for numbers (more or less explicitly recognized in the IAB's initial
agreements with the ITU that allowed work to move forward with e164.arpa) clearly recognizes number assignee and carrier
rights with respect to numbers and these are reflected in (A) and (B). Indeed, some of us recall initial ENUM discussions that explicitly considered a role for carriers. These were abandoned more for lack of interest and technical complexity than a consensus that carriers had no rights. User and Carrier roles are often codified with some variations in law. While other categories, such as resellers, exist, these are usually handled through either the user or the carrier framework. And indeed, one could argue that putative parties in (D) could get ENUM RRs populated either through the user tree (A) or through the underlying network service provider (B). 
>From the beginning, the fact that ENUM would be used in private arrangements (C) was always understood.
So, while I understand the logical concept of (D), I don't see it as a reason to deny carriers a tree moving forward any more than I would see it as a reason to deny users their tree. If countries should accord specific rights with respect to parties that are neither users nor carriers of record, I suspect countries would have it in their power, as part of delegation rights for any global user or carrier tree to require specific administrative arrangements to provide those rights in the carrier and/or user trees.
I believe that the concern with the memo that you and Rich distributed previously was that it suggested reservations about going forward with a request to the ITU to consider establishing a global apex for (B). Many of us had thought that the WG had come to a consensus to do this. Realistically, establishing a global regime for (B) may be the best way of protecting the interests of those concerned with D following the logic stated above that national authorities would then have a way of enforcing whatever rights they chose to accord such parties. 
The alternative to (B) is not further work towards some sort arrangement to provide for (D) but simply that carriers will organize private national or global trees under which the parties whose interests you are concerned about re (D) would have no standing. This is the course that the GSMA is taking, for example.

Penn

-----Original Message----th ESMTP id l2IKqosY010119; 
	Sun, 18 Mar 2007 16:52:50 -0400 (EDT)
Content-class: urn:content-classes:message
Subject: RE: [Enum] My view of where we are in ENUM
Date: Sun, 18 Mar 2007 16:52:42 -0400
From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], The IESG <[email-masked]>

Patrik:
I would tend to agree with your parsing of the different varieties of ENUM with the possible exception of D.
The real world and its regulatory framework for numbers (more or less explicitly recognized in the IAB's initial
agreements with the ITU that allowed work to move forward with e164.arpa) clearly recognizes number assignee and carrier
rights with respect to numbers and these are reflected in (A) and (B). Indeed, some of us recall initial ENUM discussions that explicitly considered a role for carriers. These were abandoned more for lack of interest and technical complexity than a consensus that carriers had no rights. User and Carrier roles are often codified with some variations in law. While other categories, such as resellers, exist, these are usually handled through either the user or the carrier framework. And indeed, one could argue that putative parties in (D) could get ENUM RRs populated either through the user tree (A) or through the underlying network service provider (B). 
>From the beginning, the fact that ENUM would be used in private arrangements (C) was always understood.
So, while I understand the logical concept of (D), I don't see it as a reason to deny carriers a tree moving forward any more than I would see it as a reason to deny users their tree. If countries should accord specific rights with respect to parties that are neither users nor carriers of record, I suspect countries would have it in their power, as part of delegation rights for any global user or carrier tree to require specific administrative arrangements to provide those rights in the carrier and/or user trees.
I believe that the concern with the memo that you and Rich distributed previously was that it suggested reservations about going forward with a request to the ITU to consider establishing a global apex for (B). Many of us had thought that the WG had come to a consensus to do this. Realistically, establishing a global regime for (B) may be the best way of protecting the interests of those concerned with D following the logic stated above that national authorities would then have a way of enforcing whatever rights they chose to accord such parties. 
The alternative to (B) is not further work towards some sort arrangement to provide for (D) but simply that carriers will organize private national or global trees under which the parties whose interests you are concerned about re (D) would have no standing. This is the course that the GSMA is taking, for example.

Penn

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]] 
Sent: Sunday, March 18, 2007 10:24 AM
To: [email-masked]
Cc: [email-masked]; The IESG
Subject: [Enum] My view of where we are in ENUM

[A] User ENUM

    ---- o -----

-
From: Patrik Fältström [mailto:[email-masked]] 
Sent: Sunday, March 18, 2007 10:24 AM
To: [email-masked]
Cc: [email-masked]; The IESG
Subject: [Enum] My view of where we are in ENUM

[A] User ENUM

---

From: "Stastny Richard" <[email-masked]>
Date: Sun, 18 Mar 2007 23:16:13 +0100

Hi Patrik,
 
I do not really see a problem here
 
I do not see A, B and C as different camps (I do not understand D),
all of these 3 are valid ENUM applications
 
As Penn is saying, C is of no concern in IETF,
A is already solved
leaves B open:

This is also solved in the WG, the drafts are there
what is missing is a statement from IETF/IESG/IAB to the ITU-T
 
My proposal is that IESG/IAB is to offer the ITU-T to use also an apex
in .arpa and also to use RIPE NCC to operate the Tier-0, 
it is the ITU-T decision to take this offer or chose another apex
(and somebody else to operate it).
 
In SG2 Q.1 already a correspondance group has been created
at the last plenary in February (the rapporteur is Karen Mulberry from Neustar)
to deal with this issue (and awaiting a liaison from IESG).
 
In addition, to my understanding nobody in ITU-T considers that
this will have any influence on e164.arpa and  the Interim Procedures.
 
So what we need to do is advancing the 4 I-Ds to RFCs and send them with a
letter to ITU-T
 
Richard

________________________________

Von: Patrik Fältström [mailto:[email-masked]]
Gesendet: So 18.03.2007 15:23
An: [email-masked]
Cc: [email-masked]; The IESG
Betreff: [Enum] My view of where we are in ENUM

[A] User ENUM

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 19 Mar 2007 01:16:30 +0100

> Actually, they could very well be in the public DNS but reside in  

Correct. We are sort of splitting hairs here. It could be everything  
form public DNS, but a "special apex", via split DNS situations using  
the same root as public DNS, to something that is not even using  
that. There are many shades of grey.

> group because their problem is already solved.

Ok, let me then rephrase myself, I do not see them participate in the  
discussions.

>> the IETF are not capable of discussing. Especially as alternative  
>> C people are present in the discussions. Those discussions are  
>> such that I think (for example) ITU-T in SG2 should discuss.
>

Because how the algorithm how you resolve the E.164 to a URI (or a  
set of URIs) end up being a quite complicated process given A+B+C,  
and how you do it MIGHT include both legal and business decisions.

I am as co-chair of this wg not comfortable declaring consensus  
without input from my AD's (although I immediately cc the IAB as they  
handle the liaison with ITU).

If the wg (or individuals of the wg) think I am wrong, that is fine.  
I accept that. The AD have to tell me what to do anyways.

I have also heard two other "complaints" on how I have handled this  
process, and I do acknowledge that as well:

(1) The discussions I have had with individuals have not been on the  
ENUM wg mailinglist, as they should. People was surprised by the  
message. I understand that.

(2) The wording of the initial message could have been different. I  
should have spent more time editing it. Based on (1) above, I should  
have understood every letter was important. I understand this as well.

I do hope you *NOW* understand what my view is.

     Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 19 Mar 2007 01:20:43 +0100

On 18 mar 2007, at 21.52, PFAUTZ, PENN L, ATTCORP wrote:

> Patrik:
> I would tend to agree with your parsing of the different varieties  
> of ENUM with the possible exception of D.

Understood. Lets ignore D for now.

> The real world and its regulatory framework for numbers (more or  
> less explicitly recognized in the IAB's initial
> agreements with the ITU that allowed work to move forward with  
> e164.arpa) clearly recognizes number assignee and carrier
> rights with respect to numbers and these are reflected in (A) and  
> (B). Indeed, some of us recall initial ENUM discussions that  
> explicitly considered a role for carriers. These were abandoned  
> more for lack of interest and technical complexity than a consensus  
> that carriers had no rights.

Correct.

> User and Carrier roles are often codified with some variations in  
> law. While other categories, such as resellers, exist, these are  
> usually handled through either the user or the carrier framework.  
> And indeed, one could argue that putative parties in (D) could get  
> ENUM RRs populated either through the user tree (A) or through the  
> underlying network service provider (B).
> So, while I understand the logical concept of (D), I don't see it  
> as a reason to deny carriers a tree moving forward any more than I  
> would see it as a reason to deny users their tree. If countries  
> should accord specific rights with respect to parties that are  
> neither users nor carriers of record, I suspect countries would  
> have it in their power, as part of delegation rights for any global  
> user or carrier tree to require specific administrative  
> arrangements to provide those rights in the carrier and/or user trees.

See previous note. Exactly HOW the branch is created (including IF  
the branch is created) have to do with so many things that is  
discussed outside of the IETF that I am (too) nervous of making a  
decision.

> I believe that the concern with the memo that you and Rich  
> distributed previously was that it suggested reservations about  
> going forward with a request to the ITU to consider establishing a  
> global apex for (B). Many of us had thought that the WG had come to  
> a consensus to do this.

Understood.

> Realistically, establishing a global regime for (B) may be the best  
> way of protecting the interests of those concerned with D following  
> the logic stated above that national authorities would then have a  
> way of enforcing whatever rights they chose to accord such parties.
> The alternative to (B) is not further work towards some sort  
> arrangement to provide for (D) but simply that carriers will  
> organize private national or global trees under which the parties  
> whose interests you are concerned about re (D) would have no  
> standing. This is the course that the GSMA is taking, for example.

GSMA is of course part of C, we all know that.

My point is that I do not feel I have enough data to declare  
consensus on how the solution for B should look like. If the IETF  
leadership give me advice, I am happy to implement in the wg whatever  
is suggested.

Regarding the suggestion to interact with ITU, that is a reflection  
on input I have got as a co-chair regarding the ITU-T SG2 discussing  
many issues that involves policy that impacts the result of the ENUM  
wg (and the SPEERMINT wg for that matter).

    Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 19 Mar 2007 01:24:45 +0100

> I do not really see a problem here

Ok.

> As Penn is saying, C is of no concern in IETF,

Well, it is FOR ME not that simple. The part that holds an E.164 in  
his hand, and is going to do resolution on it using some ENUM  
technology is going to use some algorithm. What that algorithm look  
like is something I feel I want to know before feeling comfortable,  
and that includes A, B and C (lets ignore D for now).

> what is missing is a statement from IETF/IESG/IAB to the ITU-T

I completely understand your view.

> (and somebody else to operate it).

This might be one solution. I want input from our ADs on this.

> this will have any influence on e164.arpa and  the Interim Procedures.

That is good news, if it is correct. But also, this is why I do not  
feel comfortable making any decisions before we have this input/ 
interaction/whatever.

We are not that far apart as you might think. Or what I might think :-)

> So what we need to do is advancing the 4 I-Ds to RFCs and send them  

Note that I am *NOT* suggesting any I-D should be thrown away!

    Patrik

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 19 Mar 2007 04:59:51 -0400

> From: PFAUTZ, PENN L, ATTCORP [mailto:[email-masked]]
> Sent: Sunday, March 18, 2007 4:53 PM
> To: [email-masked]
> The real world and its regulatory framework for numbers (more or less
> explicitly recognized in the IAB's initial
> agreements with the ITU that allowed work to move forward with e164.arpa)
> clearly recognizes number assignee and carrier
> rights with respect to numbers and these are reflected in (A) and (B).
> Indeed, some of us recall initial ENUM discussions that explicitly
> considered a role for carriers. These were abandoned more for lack of
> interest and technical complexity than a consensus that carriers had no
> rights. User and Carrier roles are often codified with some variations in
> law. While other categories, such as resellers, exist, these are usually
> handled through either the user or the carrier framework. And indeed, one
> could argue that putative parties in (D) could get ENUM RRs populated
> either through the user tree (A) or through the underlying network service
> provider (B).

I think we have all agreed that mixing the two is a bad idea technically and
administratively.

> So, while I understand the logical concept of (D), I don't see it as a
> reason to deny carriers a tree moving forward any more than I would see it
> as a reason to deny users their tree. If countries should accord specific
> rights with respect to parties that are neither users nor carriers of
> record, I suspect countries would have it in their power, as part of
> delegation rights for any global user or carrier tree to require specific
> administrative arrangements to prFrom [email-masked] Mon Mar 19 05:00:22 2007
From: "Richard Shockey" <[email-masked]>
To: "'PFAUTZ, PENN L, ATTCORP'" <[email-masked]>, <[email-masked]>
Subject: RE: [Enum] My view of where we are in ENUM
Date: Mon, 19 Mar 2007 04:59:51 -0400
Organization: NeuStar, Inc,
Cc: [email-masked], 'The IESG' <[email-masked]>
Reply-To: [email-masked]

> From: PFAUTZ, PENN L, ATTCORP [mailto:[email-masked]]
> Sent: Sunday, March 18, 2007 4:53 PM
> To: [email-masked]
> The real world and its regulatory framework for numbers (more or less
> explicitly recognized in the IAB's initial
> agreements with the ITU that allowed work to move forward with e164.arpa)
> clearly recognizes number assignee and carrier
> rights with respect to numbers and these are reflected in (A) and (B).
> Indeed, some of us recall initial ENUM discussions that explicitly
> considered a role for carriers. These were abandoned more for lack of
> interest and technical complexity than a consensus that carriers had no
> rights. User and Carrier roles are often codified with some variations in
> law. While other categories, such as resellers, exist, these are usually
> handled through either the user or the carrier framework. And indeed, one
> could argue that putative parties in (D) could get ENUM RRs populated
> either through the user tree (A) or through the underlying network service
> provider (B).

I think we have all agreed that mixing the two is a bad idea technically and
administratively.

> So, while I understand the logical concept of (D), I don't see it as a
> reason to deny carriers a tree moving forward any more than I would see it
> as a reason to deny users their tree. If countries should accord specific
> rights with respect to parties that are neither users nor carriers of
> record, I suspect countries would have it in their power, as part of
> delegation rights for any global user or carrier tree to require specific
> administrative arrangements to provide those rights in the carrier and/or
> user trees.

Penn the issue as Patrik and I see it is that no one is denying carriers
their own public apex for Infrastructure ENUM ..its only that the ITU not
the IETF can ultimately make that decision and what the appropriate
administrative procedures are surrounding that apex.

> I believe that the concern with the memo that you and Rich distributed
> previously was that it suggested reservations about going forward with a
> request to the ITU to consider establishing a global apex for (B). Many of
> us had thought that the WG had come to a consensus to do this.

The WG may have come to consensus to define an apex but we the WG chairs (
and many others) felt an obligation to point out the severe risks to the
IETF community in doing so. Which is why we expressed our views in a memo vs
an ID.

> Realistically, establishing a global regime for (B) may be the best way of
> protecting the interests of those concerned with D following the logic
> stated above that national authorities would then have a way of enforcing
> whatever rights they chose to accord such parties.
> The alternative to (B) is not further work towards some sort arrangement
> to provide for (D) but simply that carriers will organize private national
> or global trees under which the parties whose interests you are concerned
> about re (D) would have no standing. This is the course that the GSMA is
> taking, for example.

But again where is the appropriate forum for such decisions to be made...we
believe it is not in the IETF.

Again you are ignoring the issues in the DNS in general. The IETF defines
the protocols for DNS but its administrative policies and procedures are
ICANN. 

In my view again .. should the ITU believe it is the interest of the global
telecommunications community that such a new Infrastructure ENUM apex exist
it can petition the IETF to create such a domain in .apra or use any domain
it wants.

> be covide those rights in the carrier and/or
> user trees.

Penn the issue as Patrik and I see it is that no one is denying carriers
their own public apex for Infrastructure ENUM ..its only that the ITU not
the IETF can ultimately make that decision and what the appropriate
administrative procedures are surrounding that apex.

> I believe that the concern with the memo that you and Rich distributed
> previously was that it suggested reservations about going forward with a
> request to the ITU to consider establishing a global apex for (B). Many of
> us had thought that the WG had come to a consensus to do this.

The WG may have come to consensus to define an apex but we the WG chairs (
and many others) felt an obligation to point out the severe risks to the
IETF community in doing so. Which is why we expressed our views in a memo vs
an ID.

> Realistically, establishing a global regime for (B) may be the best way of
> protecting the interests of those concerned with D following the logic
> stated above that national authorities would then have a way of enforcing
> whatever rights they chose to accord such parties.
> The alternative to (B) is not further work towards some sort arrangement
> to provide for (D) but simply that carriers will organize private national
> or global trees under which the parties whose interests you are concerned
> about re (D) would have no standing. This is the course that the GSMA is
> taking, for example.

But again where is the appropriate forum for such decisions to be made...we
believe it is not in the IETF.

Again you are ignoring the issues in the DNS in general. The IETF defines
the protocols for DNS but its administrative policies and procedures are
ICANN. 

In my view again .. should the ITU believe it is the interest of the global
telecommunications community that such a new Infrastructure ENUM apex exist
it can petition the IETF to create such a domain in .apra or use any domain
it wants.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 19 Mar 2007 10:30:26 +0100

On 19 mar 2007, at 09.59, Richard Shockey wrote:

> its only that the ITU not

Let me phrase this differently, because I think I understand where  
the sensitivity is. In what Richard is saying lies two things:

1. As co-chairs we can not, given the landscape, declare consensus  
that we need a branch and a specific apex for that branch. We need  
input from AD/IAB.

2. We suggest IAB/IETF cooperate with ITU-T on the question, but  
whether any question is to be sent etc is a decision that lies with  
IAB and IESG.

    Patrik

---

From: Andrew Newton <[email-masked]>
Date: Mon, 19 Mar 2007 06:01:58 -0400

On Mar 18, 2007, at 6:16 PM, Stastny Richard wrote:

> As Penn is saying, C is of no concern in IETF

I strongly disagree with this statement.

-andy

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 19 Mar 2007 07:33:47 -0400

Hi Richard,

>it can petition the IETF to create such a domain in .apra or use any domain

Glad to see the realism here at last.  These are, after all,
the namespace and global public telecommunication
identifiers of ITU-T and domestically of member
administrations.  In the U.S., the namespace is explicitly
subject to the Communications Act of 1996 and
managed by the FCC pursuant to Part 52 of its Rules.

Shortly, in the U.S. the assignment of those numbers
will be subject to a charge that among other things
will pay the costs of administrative contractors like
NeuStar.  In Europe, their use is subject to the Data
Retention Directive.

What protocols, platforms, or leafs are used to
implement the authoritative resolution of the
identifiers for public telecommunication services
are irrelevant to the matter of jurisdiction and
regulatory requirements.

--tony

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Mon, 19 Mar 2007 07:56:22 -0400

OK. I think all we were looking for was a recognition of working group consensus to ask for an apex and a corresponding recommendation to the IAB/IESG (following AD concurrence) to forward the issue to the ITU. 

Penn
-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]] 
Sent: Monday, March 19, 2007 5:30 AM
To: [email-masked]
Cc: PFAUTZ, PENN L, ATTCORP; [email-masked]; [email-masked]; 'The IESG'
Subject: Re: [Enum] My view of where we are in ENUM

    Patrik

---

From: Jim Reid <[email-masked]>
Date: Sun, 18 Mar 2007 22:19:22 +0000

> group because their problem is already solved.

That's not true either Andy. There's a forest of disjoint trees out  
there. So many of those in group C have solved their immediate  
problem. But at the expense of even bigger problems of  
interconnecting name spaces with competitors who use different trees  
and/or name spaces.

And just because those guys don't come to the ENUM WG doesn't mean  
there isn't a problem. This is why I believe there's a role for the  
WG and the IESG/IAB to work out an apex (at the very least) for  
private infrastructure ENUM. If it's not the IETF that does this, who  
will? Or could?

---

From: Andrew Newton <[email-masked]>
Date: Tue, 20 Mar 2007 06:36:05 -0400

On Mar 18, 2007, at 6:19 PM, Jim Reid wrote:

> interconnecting name spaces with competitors who use different  
> trees and/or name spaces.

Well, there was a proposal in ENUM that would have fixed the disjoint  
problem you are talking about for the people in the C area (private  
ENUM trees).  The problem is, the proposal was identified with B  
needs (public infrastructure ENUM) and thus has progressed nowhere.   
I think that speaks well of Patrik's point about no consensus.

> private infrastructure ENUM. If it's not the IETF that does this,  
> who will? Or could?

I'm well aware of the problem, but there are other solutions to it  
that do not require protocol standardization.  I have a programmer  
working on it right now.

As for an apex for private infrastructure ENUM, I don't think that is  
necessary and would create far more problems than it would solve.  In  
the end, wouldn't it look like a domain registry?  Is there something  
special about an anointed apex that cannot be solved by the use of  
normal domain names?  I don't think the DNS protocol cares, therefore  
this sounds like a question for the ITU or ICANN.

-andy