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

There are both national and international UPT numbers
under discussion for years. In some countries there are
or will be soon available ENUM (e164.arpa) driven
number ranges (+43780, +42360, etc). There is also
an international range +87810 available.
 
Do you know what and how long it takes to get
+8787 assigned by ITU-T? But this is the lesser
problem: Do you know what it takes to get a new
CC routed in all countries of the world by all providers
in this country?  Forget it. For Liechtenstein, the last
country with a new CC, it took 3 years and it was a
nightmare.
 
This is the major reason why +87810 is still not up
and running. If you use a national number, the number
can at least by routed via the country as a default.
 
Richard

	-----Ursprüngliche Nachricht----- 
	Von: Patrik Fältström [mailto:paf at cisco.com] 
	Gesendet: Mo 09.08.2004 20:32 
	An: Chris Heinze 
	Cc: enum-wg at ripe.net 
	Betreff: Re: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public
	
	

	Wether you have issues with non-geographical E.164 or not depends a lot 
	of what regulation there is on E.164 numbers in the country code you 
	want numbers in. Other examples of issues include portability to other 
	providers.
	
	Example: Sweden (+46) require portability between providers of voice 
	services, but do not have geographical portability (yet). This imply if 
	you as an operator in Sweden you have to allow people to move their 
	number both to and from you.
	
	My point is not that your idea is wrong, but that you have to take into 
	account a number of different issues...
	
	Can you be more specific on what the rules are for E.164 numbers in 
	your neck of the woods?
	
	     paf
	
	On Aug 9, 2004, at 16:53, Chris Heinze wrote:
	
	> 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
	>