[enum-wg] Proposal for non-geographic ENUM E.164 UPTS for the general public

hi!

the company i'm with is providing services in the voip-area, and we had 
and still have our problems with the situation with telephone-numbers 
for voip-services in general. we were observing that other companies 
have the same and similar problems, and that several - mostly quite ugly 
- workarounds are being started, but that's all not very promising. also 
recent trials and decisions in our region didn't make us very confident 
that there's a working solution to this problem anywhere in sight.
so we thought it might be a good time to start a discussion about 
possible solutions to the telephone-number problems, and we consider the 
just-in-time creation of the ripe enum-wg a good omen. ;) we put 
together a kind of proposal for a possible solution, just to contribute 
to the discussion and have something to talk about.

we're very curious whether there is general support for a request of 
non-geographical E.164 UPTS-space for enduser-assignments handled by 
public registries, and in case there is, what is your idea about the 
following proposal, what should be done different?
we're hoping some proposal for action towards some solution that is 
capable of finding consensus in the WG and the respective other involved 
institutions can be produced.

so let's become formal and to the point:

----- snip -----

Proposal for a public registry system for non-geographic E.164 UPTS 
assignments and the respective ENUM space
=============================================================================================================

Version
-------
This document is version 0.1 of the ENUM E.164 UPTS proposal, dated 16 
June 2004.

Status
------
This document is still in draft form and is open to discussion from all 
parties.

Scope
-----
The intended audience for this document is the RIPE ENUM-WG. Once 
consensus has been reached the intended audience should be expanded to 
RIPE Services-WG, RIPE DNS-WG, RIPE DB-WG, RIPE Policy-WG, the 
respective groups of the other RIRs, and/or any other involved parties. 
Comments to the authors are encouraged.

1. Introduction
---------------
In today's internet there is already a large variety of digits-only VoIP 
devices on the market, also working VoIP-PSTN-gates are available.
In the same time there is no registry able to provide for assignments of 
appropriate telephone numbers according to ITU-T E.164 (i.e. reachable 
in the international telephone system) and the respective ENUM 
delegation to the general public.
Currently workarounds are being developed (reassignments of 
geographic-CC numbers, alternative ENUM-trees, non-regional national CC 
numbers, etc.) resulting in isolated numberspaces, user confusion, and 
possible future problems resulting from lack of coordination.
Because of this current situation there is an immediate need for 
non-geographic ENUM enabled E.164 UPTS space available for assignments 
to the general public, and creation of a structure to handle registry 
tasks, both administrative and operational.

2. Goals
--------
The requirements for the registry:
- provide undiscriminatory service to the general public (which implies 
independence towards commercial markets and nations)
- provide global service (which implies independence from nations)
- provide stable registry and ENUM service
- development of policies (which implies the need for some sort of 
legitimation from the community)
The requirements for the number space:
- part of the international telephone number space (implies ITU-T E.164)
- non-geographic
- enduser-specific (UPTS)
- fully portable

3. Registry System
------------------
The NRO as the 'community of RIRs', meeting all requirements and already 
providing a working structure and experience for such a registry, acts 
as the formal registry (Tier 1) for the assigned ENUM E.164 UPTS space.

3.1 Registry: allocations/assignments
-------------------------------------
The RIPE (or a different RIR acting as central coordination point) 
allocates parts of the assigned ENUM E.164 UPTS space to the RIRs 
(including itself).
The RIRs allocate parts of their respective allocations to their LIRs.
LIRs assign numbers from their blocks to endusers.
Assignments are enduser-specific (like IPv4 PI), i.e. the allocation to 
LIRs is just for new assignments, when an enduser changes 
serviceproviders the authority for the assignment moves with the enduser.

3.2 Registry: database
----------------------
As database for allocations and assignments, whois is used.
The whole block assigned by ITU-T is entered as one domain object, with 
mnt and mnt-lower set to an appropriate maintainer from RIPE (or a 
different RIR acting as central coordination point). When a block is 
allocated to a RIR, RIPE creates the respective domain object, entering 
an appropriate maintainer from the respective RIR as mnt and mnt-lower. 
When a block is allocated to a LIR, the respective RIR creates the 
respective domain object, entering an appropriate maintainer from the 
respective LIR as mnt and mnt-lower. When a number is assigned to an 
enduser, a maintainer according to the enduser's wishes might be 
entered. When the enduser changes service providers, a different 
maintainer can be entered.

3.3 Registry: ENUM
------------------
ENUM delegations are done upon allocation or assignment, i.e.:
ITU-T (resp. RIPE acting as Tier 0 for ITU-T) delegates ENUM for the 
assigned block to RIPE (or a different RIR acting as central 
coordination point).
When a block is allocated to a RIR, the respective ENUM delegations to 
the RIR are done.
The RIR creates its delegations from its database by querying for all 
most-specific objects (this is important to achieve full portability).

3.4 Registry: ENUM delegation from database
-------------------------------------------
RIPE (or a different RIR acting as central coordination point) has to 
make sure that upon allocation of a block to a RIR, the necessary ENUM 
delegations are made. As the kind of mechanism used to achieve this 
doesn't influence procedures in the RIRs, it's only the central 
coordination point's matter how this is done. But this could be done by 
the nserver attributes of the domain objects entered upon allocation, 
and the nameserver configuration could easily be created automatically 
in such a way.
RIRs have to generate delegations in their nameservers from the most 
specific domain objects. This way the necessary nameserver configuration 
can be created automatically, isn't dependent on a fixed 
allocation/assignment length, and provides for full portability.

3.5 Registry: policies
----------------------
A policy for allocation of blocks to the RIRs should be developed in the 
NRO context.
A policy for allocation of blocks to the LIRs and a policy for 
assignment to endusers by LIRs should be developed by the respective 
RIR, but common policies (via NRO) might be desirable.
All allocations or assignments should be done on request only, a initial 
automatic allocation of blocks to RIR-members should be deprecated for 
number space conservation reasons. The assignment policy for LIRs should 
demonstrate what is considered good practise. Possible norms could 
regard to the size of blocks assigned to entities (e.g. a fixed 
assignment length), the number of assignments to entities, and whether 
an assignment has to be deleted when the enduser is giving it up (i.e. 
does it have to be available for reassignment by the LIR who initially 
received the respective block for new assignments or is it ok for the 
last maintainer/service provider to reuse it?).
LIRs receive allocations of blocks from RIRs as a means of moving the 
work necessary for assignments to the member-level where the request was 
delivered, and where service is done directly to the enduser. To install 
some kind of quality assurance, it's proposed to introduce a slow-start 
mechanism just like with IPv4 PA assignments: initial assignments have 
to be approved by a RIR hostmaster, until it is decided by the RIR to 
give the LIR an assignment window, which will be increased when the LIR 
demonstrated sufficient experience.

4. E.164 UPTS space
-------------------
The RIRs request from the ITU-T TSB assignment of non-geographic E.164 
UPTS space (i.e. a block under CC878) to the NRO and the respective ENUM 
delegation to RIPE.
It might be worth considering explicitly requesting a short (i.e. 1 
digit) prefix to have a number space as large as possible to attenuate 
ENUM block-delegation issues. I guess the community might like the idea 
of a sub-block identifier '7' (i.e. +8787 with an 11 digits space)

5. Actions
----------
1.) discussion in RIPE ENUM-WG on UPTS-space for enduser-assignments 
handled by RIRs
in case of general support of ENUM-WG:
2.) discussion in RIPE ENUM-WG, Services-WG, DNS-WG, and DB-WG on 
request for registry service (tier 1) operations run by RIPE
in case of general support of ENUM-WG and Services-WG:
3.) discussion in RIPE Address Policy-WG on ENUM878x 
allocation/assignment policies
in case of a consensus on (preliminary) policies:
4.) discussion in NRO context (actions 2, 3, and 4 might be intermixed)
in case of a consensus on (preliminary) policies:
5.) request to ITU-T TSB for delegation of a non-geographic UPTS block 
under E.164 CC878 to the RIRs (formally NRO, or RIPE acting in consensus 
with RIR-community)

----- snap -----

kind regards,

         Chris Heinze