[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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

Penn


-----Original Message-----
From: Patrik Fältström [mailto:paf at cisco.com]
Sent: Sunday, March 18, 2007 10:24 AM
To: enum at ietf.org
Cc: iab at ietf.org; The IESG
Subject: [Enum] My view of where we are in ENUM

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
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

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


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