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

Patrik is right about the issues will be different for non-geographic
numbers based on local regulations.  Here is a link to some current work the
ENUM-Forum has done in the US.

http://www.enumf.org/documents/gen/2004/GEN0096R0_Lind_Non-Geo_Document-2.do
c

http://www.enumf.org/documents/gen/2004/GEN0101R0_Greenhaus_Provisioning_Tol
l_Free.doc

Also, I think the ITU-T SG2 has some documents on this very issue.  


Kevin....

> -----Original Message-----
> From: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] 
> On Behalf Of Patrik Fältström
> Sent: Monday, August 09, 2004 1:32 PM
> To: Chris Heinze
> Cc: enum-wg at ripe.net
> Subject: 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
> >
>