[Enum] My view of where we are in ENUM

[Patrik Fältström <paf at cisco.com>]

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