[enum-wg] repost: 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