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

["Richard Shockey" <richard at shockey.us>]

> -----Original Message-----
> From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz at att.com]
> Sent: Sunday, March 18, 2007 4:53 PM
> To: enum at ietf.org
> Cc: iab at ietf.org; The IESG
> Subject: RE: [Enum] My view of where we are in ENUM
> 
> 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).

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

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

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.


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