enum-wg

Download

enum-wg@ripe.net

June 2004

1 participants
1 discussions

Proposal for non-geographic ENUM E.164 UPTS for the general public
by Chris Heinze 16 Jun '04

16 Jun '04

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

1 0