From webmaster at ripe.net Thu Aug 5 16:29:48 2004 From: webmaster at ripe.net (RIPE NCC WebMaster) Date: Thu, 05 Aug 2004 16:29:48 +0200 Subject: [enum-wg] Closing Message-ID: <200408051429.i75ETmW7014126@birch.ripe.net> Dear Colleagues, Following the official formation of the ENUM Working Group at RIPE 48, Amsterdam we have moved all subscribers of to the newly created working group mailing list . The mailing list will shortly be closed. If you wish to unsubscribe from please enter your e-mail address in the form at the bottom of the page found at: http://www/mailman/listinfo/enum-wg More information about the ENUM Working Group can be found at: http://www.ripe.net/ripe/wg/enum/index.html If you experience any problems please mail . Regards, RIPE NCC WEBMASTER ================== From x at ccn.net Mon Aug 9 16:53:24 2004 From: x at ccn.net (Chris Heinze) Date: Mon, 09 Aug 2004 16:53:24 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public Message-ID: <41178FE4.2090802@ccn.net> 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 From paf at cisco.com Mon Aug 9 20:32:25 2004 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 9 Aug 2004 20:32:25 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <41178FE4.2090802@ccn.net> References: <41178FE4.2090802@ccn.net> Message-ID: <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> 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 > From KMcCandless at verisign.com Mon Aug 9 21:00:16 2004 From: KMcCandless at verisign.com (McCandless, Kevin) Date: Mon, 9 Aug 2004 14:00:16 -0500 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public Message-ID: <318266A4431BC549B4C4D6FD3EA6E24D03AFBA3D@ove1wnexm01.vcorp.ad.vrsn.com> 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 > > > From Richard.Stastny at oefeg.at Mon Aug 9 21:04:46 2004 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Mon, 9 Aug 2004 21:04:46 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public Message-ID: <06CF906FE3998C4E944213062009F162443845@oefeg-s02.oefeg.loc> 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 > From jim at rfc1035.com Mon Aug 9 21:15:41 2004 From: jim at rfc1035.com (Jim Reid) Date: Mon, 09 Aug 2004 20:15:41 +0100 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: Message from =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= of "Mon, 09 Aug 2004 20:32:25 +0200." <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> Message-ID: <6649.1092078941@gromit.rfc1035.com> I think Chris's idea is good in principle, though I'm not sure about its practicality. As Patrik says, use of non-geographic E.164 numbers touches on awkward corners of national telephony regulations. I think the ITU would take a dim view of this too. And that's aside from them being uneasy (unable?) about issuing a chunk of E.164 number space to an organisation that isn't an ITU member. IIUC ITU directly controls E.164 numbers used for Universal Personal Telephony, so they could well be touchy about another entrant into that space. There would also be a conflict of interest given that RIPE NCC is already operating the registry for e164.arpa. So if the NCC was to apply for a non-geographic E.164 code and get it, this would probably need to be administered by a separate organisation from that running the e164.arpa registry. From paf at cisco.com Mon Aug 9 21:31:31 2004 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 9 Aug 2004 21:31:31 +0200 Subject: [enum-wg] New Subject: What ENUM wg should do... In-Reply-To: <6649.1092078941@gromit.rfc1035.com> References: <6649.1092078941@gromit.rfc1035.com> Message-ID: One of the things Kim and I have planned for this wg is to keep a webpage updated with, for each CC/country, answers to questions on what rules exists for various things -- one of them being how integration of E.164 numbers is... But, questions are not to 100% ready yet. Basis comes from Joakim Str?lmark of PTS (the regulator) in Sweden. Some of you might already have seen them. More info from Kim. Both Kim and myself (like many of you) are still deflating after an intense week at the IETF last week, but at the end of this week you should get more info from us. Does this sound like a "good thing for this wg to do"? paf From jim at rfc1035.com Mon Aug 9 21:50:49 2004 From: jim at rfc1035.com (Jim Reid) Date: Mon, 09 Aug 2004 20:50:49 +0100 Subject: [enum-wg] New Subject: What ENUM wg should do... In-Reply-To: Message from =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= of "Mon, 09 Aug 2004 21:31:31 +0200." Message-ID: <6742.1092081049@gromit.rfc1035.com> >>>>> "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= writes: paf> One of the things Kim and I have planned for this wg is to paf> keep a webpage updated with, for each CC/country, answers to paf> questions on what rules exists for various things -- one of paf> them being how integration of E.164 numbers is... paf> Does this sound like a "good thing for this wg to do"? YES! From paf at cisco.com Mon Aug 9 22:03:23 2004 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 9 Aug 2004 22:03:23 +0200 Subject: [enum-wg] New Subject: What ENUM wg should do... In-Reply-To: <6742.1092081049@gromit.rfc1035.com> References: <6742.1092081049@gromit.rfc1035.com> Message-ID: <2B54B8E2-EA3F-11D8-BA68-000A95B2B926@cisco.com> On Aug 9, 2004, at 21:50, Jim Reid wrote: >>>>>> "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= >>>>>> writes: > > paf> One of the things Kim and I have planned for this wg is to > paf> keep a webpage updated with, for each CC/country, answers to > paf> questions on what rules exists for various things -- one of > paf> them being how integration of E.164 numbers is... > > paf> Does this sound like a "good thing for this wg to do"? > > YES! Ok, Kim, let me know when you have the basic web page up and running, and I'll work on the questions. paf From ag at ag-projects.com Mon Aug 9 22:02:58 2004 From: ag at ag-projects.com (Adrian Georgescu) Date: Mon, 9 Aug 2004 22:02:58 +0200 Subject: [enum-wg] New Subject: What ENUM wg should do... In-Reply-To: References: <6649.1092078941@gromit.rfc1035.com> Message-ID: <1C67C57C-EA3F-11D8-9C4C-000A95C7765A@ag-projects.com> Yes, bringing facts from various countries over the subject sounds like a good thing to do! Adrian On Aug 9, 2004, at 9:31 PM, Patrik F?ltstr?m wrote: > One of the things Kim and I have planned for this wg is to keep a > webpage updated with, for each CC/country, answers to questions on > what rules exists for various things -- one of them being how > integration of E.164 numbers is... > > But, questions are not to 100% ready yet. Basis comes from Joakim > Str?lmark of PTS (the regulator) in Sweden. Some of you might already > have seen them. > > More info from Kim. > > Both Kim and myself (like many of you) are still deflating after an > intense week at the IETF last week, but at the end of this week you > should get more info from us. > > Does this sound like a "good thing for this wg to do"? > > paf > > From james at seng.cc Tue Aug 10 01:49:22 2004 From: james at seng.cc (James Seng) Date: Tue, 10 Aug 2004 07:49:22 +0800 Subject: [enum-wg] New Subject: What ENUM wg should do... In-Reply-To: <6742.1092081049@gromit.rfc1035.com> References: <6742.1092081049@gromit.rfc1035.com> Message-ID: <41180D82.40705@seng.cc> IETF or RIPE WG? I'm all for it for the latter. -James Seng Jim Reid wrote: >>>>>>"paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= writes: > > > paf> One of the things Kim and I have planned for this wg is to > paf> keep a webpage updated with, for each CC/country, answers to > paf> questions on what rules exists for various things -- one of > paf> them being how integration of E.164 numbers is... > > paf> Does this sound like a "good thing for this wg to do"? > > YES! > > > From james at seng.cc Tue Aug 10 01:50:46 2004 From: james at seng.cc (James Seng) Date: Tue, 10 Aug 2004 07:50:46 +0800 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <41178FE4.2090802@ccn.net> References: <41178FE4.2090802@ccn.net> Message-ID: <41180DD6.10202@seng.cc> How is this proposed +8787 different from the current +87810? (Other then the goverance portion?) -James Seng 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: From paf at cisco.com Tue Aug 10 02:14:28 2004 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Tue, 10 Aug 2004 02:14:28 +0200 Subject: [enum-wg] New Subject: What ENUM wg should do... In-Reply-To: <41180D82.40705@seng.cc> References: <6742.1092081049@gromit.rfc1035.com> <41180D82.40705@seng.cc> Message-ID: <3ED4B8A4-EA62-11D8-BA68-000A95B2B926@cisco.com> On Aug 10, 2004, at 01:49, James Seng wrote: > IETF or RIPE WG? I'm all for it for the latter. RIPE-WG. paf > > -James Seng > > Jim Reid wrote: > >>>>>>> "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= >>>>>>> writes: >> paf> One of the things Kim and I have planned for this wg is to >> paf> keep a webpage updated with, for each CC/country, answers to >> paf> questions on what rules exists for various things -- one of >> paf> them being how integration of E.164 numbers is... >> paf> Does this sound like a "good thing for this wg to do"? >> YES! From x at ccn.net Tue Aug 10 09:26:23 2004 From: x at ccn.net (Chris Heinze) Date: Tue, 10 Aug 2004 09:26:23 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> Message-ID: <4118789F.2000505@ccn.net> hi! > 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. this is true for geographical i.e. cc-number space, but not for numbers from non-geographic prefixes. +878 is non-geographical space, a 'country code' not assigned to a region or state. the idea is to have a prefix allocated to the RIRs, and of course there have to be policies for this number space at the RIRs - i guess the RIR/NRO context is a perfect place to create such policies. > Other examples of issues include portability to other > providers. right. the idea behind non-geographic space is its good reference of voip-requirements. if number porability to pstn users is desired, the whois-solution should work for these cases too, if a pstn provider wants to offer portability to pstn i guess this implies a solution for the pstn-side by the requesting provider (probably more easy e.g. in mobile networks). but in case this space will never be used in pstn networks, it still is a helpful and good solution for voip-users. > 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. this is regulation of the +46 cc-number space, i guess. otherwise if you say 'numbers' certainly PA space would be a problem, probably domain names, etc. but even if regulations in one country prohibit users and providers to use global numbers for voip, in other countries this would still be a preferable solution. > My point is not that your idea is wrong, but that you have to take > into account a number of different issues... certainly. i hope this is the right place for a discussion for these issues, and for finding good solutions for identified problems. :) > Can you be more specific on what the rules are for E.164 numbers in > your neck of the woods? that's germany. +49 numbers are in their regions fully portable between pstn providers. currently large regional blocks are reallocated by voip gateway providers to voip-users. so a voip-user from e.g. dresden can have a number from e.g. duesseldorf, hamburg, berlin, munich - or all of them. that's really ugly but voip providers actually have no big choice. there is a 'region' reserved for non-regional (in the end of course still national) numbers (+4932), but this is currently discussed and it's unlikely that this prefix will be useably anytime soon. also, there are strong doubts that this prefix will be freely available to voip-providers, the current discussion shows that there will probably be dependencies and drawbacks especially for voip. kind regards, Chris Heinze From x at ccn.net Tue Aug 10 09:47:15 2004 From: x at ccn.net (Chris Heinze) Date: Tue, 10 Aug 2004 09:47:15 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <06CF906FE3998C4E944213062009F162443845@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F162443845@oefeg-s02.oefeg.loc> Message-ID: <41187D83.7010609@ccn.net> hi! > 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. as for the national enum number spaces, just a few are decided, others are in discussion at a stage where results can not be foreseen, and in most cases non-regional enum prefixes are not in sight. also, national prefixes are still a bad idea for global nomadic use, they are national. do you regard +87810 as available to the general public? are the numbers portable so that, let's say, a customer of yours wants to transfer services to us, will you change enum delegation? > Do you know what and how long it takes to get > +8787 assigned by ITU-T? i know how long it took visionng. plus, the 7 was of course just an idea. probably the ITU just delegates 2-number-delegations under +878. but in case there is sympathy for the idea and a mutual wish to provide for a large space, the 7 would certainly be a nice choice ;) > 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? well there are certainly no chances to have increasing reachability without getting the prefix started. i guess a RIR/NRO allocated space with its vast amount of users has the potential to speed this process up, in comparison to other cases. also, i hope that it's possible to take advantage of experience of individuals in this community, so e.g. i guess you could provide valuable input for the ITU-T TSB +878* delegation application, so that it could be avoided to have a rejected application because of formal errors in the first place. actually i beleive the issues regarding routing would be very different from e.g. a 'real' cc-prefix. i beleive this is a very complex topic, my assessment is that at large it will probably be easier, while it's in the same time not crucial to have a good reachability from pstn right from the start. in case of ripe as the tier 1 i'd even be very positive about remarkably flawless operation in voip/enum networks right from the beginning. > Forget it. For Liechtenstein, the last > country with a new CC, it took 3 years and it was a > nightmare. good that they had it started, because it was probably a good idea anyway :) simply not trying to get a prefix for global portable upts available to the general public won't help to solve the needs of voip-users. > This is the major reason why +87810 is still not up > and running. maybe the proposal could provide for better motivation to speed things up, in the end the represented community is much bigger and actual demands will certainly bring things forward. > If you use a national number, the number > can at least by routed via the country as a default. ...and this works. that's true. still, i think it's a good idea to start a good solution to the questions emerging in new technologies - even if they take long to realise. when you say routed via the country as default, do you have international portability in mind? also, from your post i get the impression you gave up on +87810? kind regards, Chris Heinze From x at ccn.net Tue Aug 10 09:54:01 2004 From: x at ccn.net (Chris Heinze) Date: Tue, 10 Aug 2004 09:54:01 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <6649.1092078941@gromit.rfc1035.com> References: <6649.1092078941@gromit.rfc1035.com> Message-ID: <41187F19.7060900@ccn.net> hi! > I think Chris's idea is good in principle, though I'm not sure about > its practicality. As Patrik says, use of non-geographic E.164 numbers > touches on awkward corners of national telephony regulations. I think > the ITU would take a dim view of this too. And that's aside from them > being uneasy (unable?) about issuing a chunk of E.164 number space to > an organisation that isn't an ITU member. IIUC ITU directly controls > E.164 numbers used for Universal Personal Telephony, so they could > well be touchy about another entrant into that space. ah, thanks for this kind of input, for me personally that's most interesting, because it's sometimes really hard to get a good view on ITU procedures. can you think of a practical solution to satisfy the ITU's needs? maybe richard stasny can tell us more, the status of visionng is a private organisation afaik, so delegation of space under +878 is obviously not impossible, i even guess chances are that ITU might prefer RIRs as the organizations who proved that they are capable of doing a very good job on coordinating number resources and making them available to the general public in a free and nondiscriminating manner. also, i guess the needs of voip users would be served if the RIRs/NRO operate the delegation process using polices from the ITU, the idea was not to take away control from somebody. actually, if the ITU provides for a similar solution, i know of a large community that would be more than happy, no matter whether RIRs or the ITU were in charge - but i also think it wasn't a bad choice for ITU to delegate tier 0 operation to RIPE. > There would also be a conflict of interest given that RIPE NCC is > already operating the registry for e164.arpa. So if the NCC was to > apply for a non-geographic E.164 code and get it, this would probably > need to be administered by a separate organisation from that running > the e164.arpa registry. i guess it's a sub-optimal idea to allocate the block to RIPE and RIPE only, the community of RIRs probably in the form of the NRO would be a better idea, as the space is meant to be used globally. actually the work RIPE did up to now as tier 0 operator demonstrates the high qualifications of RIPE as an enum-operator at the tier 0 and tier 1 levels quite convincingly. kind regards, Chris Heinze From x at ccn.net Tue Aug 10 09:56:20 2004 From: x at ccn.net (Chris Heinze) Date: Tue, 10 Aug 2004 09:56:20 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <41180DD6.10202@seng.cc> References: <41178FE4.2090802@ccn.net> <41180DD6.10202@seng.cc> Message-ID: <41187FA4.7040903@ccn.net> hi! > How is this proposed +8787 different from the current +87810? (Other > then the goverance portion?) visionng is set up as an organization to support its members. this is a different approach than the one of the RIRs which is aimed at the community of all internet users. visionng's aim is to support a set of specific technical solutions, it requires its members to adopt a specific technical framework that has been decided upon in the visionng context. the number space was probably requested by visionng because of the lack of available non geographic upts, managing such a number resource for the general public wasn't the aim. visionng does not actually focus on voip or the ip part alone, but also on PSTN networks and technology. also, i guess compared to the RIRs visionng generally cannot be seen as an open organization, it is not aimed at and probably can not provide for upts for the general public. visionng seems to be somebody who could profit from the proposed setup, as the numbers would be portable to and from pstn of visionng members. but if you wish to know more about visionng, it's certainly a beter idea to ask richard stasny. kind regards, Chris Heinze From enumvoipsip.cs at schiefner.de Tue Aug 10 13:40:56 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Tue, 10 Aug 2004 13:40:56 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <4118789F.2000505@ccn.net> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> Message-ID: <4118B448.3050808@schiefner.de> Hi Chris, Chris Heinze wrote: > that's germany. +49 numbers are in their regions fully portable between > pstn providers. currently large regional blocks are reallocated by voip > gateway providers to voip-users. so a voip-user from e.g. dresden can > have a number from e.g. duesseldorf, hamburg, berlin, munich - or all of > them. ... and which AFAIK is of some major concern to the regulator. Apart from the fact that they don't have any real means at hand right now, they do not get tired of repeating their unhappiness. > that's really ugly but voip providers actually have no big choice. > there is a 'region' reserved for non-regional (in the end of course > still national) numbers (+4932), but this is currently discussed and > it's unlikely that this prefix will be useably anytime soon. also, there > are strong doubts that this prefix will be freely available to > voip-providers, the current discussion shows that there will probably be > dependencies and drawbacks especially for voip. That is one of my concerns - that according to the current draft only "real" telcos can get numbers or blocks out of that range. So any VoIP only provider just has to rely on others instead of being able to deal with the regulator directly. Another one is (and I find that in your proposal, too) the idea of allocating/assigning blocks: at the end of the day we are also talking domains here. In the domain world such a concept is totally unknown (for good reasons!) and would not really be feaseble: get domain names starting with a to k from registrar A and from l to z from registrar B...?! As you have to ensure portability in the long run anyways: why not assigning a number out of such blocks (whether it's +878xx, +4932 or something else) directly to the user? S/he can port the number to a provider of an own choice without creating "holes" in blocks allocated or assigned to providers/LIRs/... IMHO the difference really is that people (apart from very few ;-) do not really care about the IP addresses they get because you hardly announce them to third parties as points of contact anyways. But you certainly do with your UPT/... numbers. That, of course, would be a different registry type - more a domain registry that an RIR. But I am certainly not saying that an RIR cannot or even must not take up that business, too - given that all parties involved agree to it. Cheers, -C. From enumvoipsip.cs at schiefner.de Tue Aug 10 13:44:39 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Tue, 10 Aug 2004 13:44:39 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <41187D83.7010609@ccn.net> References: <06CF906FE3998C4E944213062009F162443845@oefeg-s02.oefeg.loc> <41187D83.7010609@ccn.net> Message-ID: <4118B527.8010601@schiefner.de> Chris Heinze wrote: > plus, the 7 was of course just an idea. probably the ITU just delegates > 2-number-delegations under +878. but in case there is sympathy for the > idea and a mutual wish to provide for a large space, the 7 would > certainly be a nice choice ;) Hmm... AFAIK the +878 extension is really two digits. But instead of having ITU changing its rules (and having to wait for it!) - why not applying for 70 to 79 in the first place? ;-> Cheers, -C. From x at ccn.net Tue Aug 10 15:18:21 2004 From: x at ccn.net (Chris Heinze) Date: Tue, 10 Aug 2004 15:18:21 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <4118B448.3050808@schiefner.de> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <4118B448.3050808@schiefner.de> Message-ID: <4118CB1D.8020908@ccn.net> hi! >> that's germany. +49 numbers are in their regions fully portable >> between pstn providers. currently large regional blocks are >> reallocated by voip gateway providers to voip-users. so a voip-user >> from e.g. dresden can have a number from e.g. duesseldorf, hamburg, >> berlin, munich - or all of them. > > > ... and which AFAIK is of some major concern to the regulator. Apart > from the fact that they don't have any real means at hand right now, > they do not get tired of repeating their unhappiness. yes - actually (except for some endusers that consider it fun to have numbers from different cities) i know of nobody who is really happy with this solution, last of all the gateway providers. there's really a need for a real solution, and in voip-context a global non-regional number space is imho most straightforward. it's hardly optimal to dial +4932.... or any other cc-number to reach a user who is currently in helsinki and might be in hongkong tomorrow... as an international prefix could be seen as a public resource that has to be available in a non-discriminating way, i beleive personal numbers assigned to the endusers are again the most straightforward solution. if blocks were allocated to providers and were only portable as the whole block, i think that would spoil portability as well as the idea of non-regional numbers. actually e.164 provides for other number space to be allocated/assigned to companies on a big block level, so when there is need for something like that, an existing global upts wouldn't spoil anything. >> that's really ugly but voip providers actually have no big choice. >> there is a 'region' reserved for non-regional (in the end of course >> still national) numbers (+4932), but this is currently discussed and >> it's unlikely that this prefix will be useably anytime soon. also, >> there are strong doubts that this prefix will be freely available to >> voip-providers, the current discussion shows that there will probably >> be dependencies and drawbacks especially for voip. > > > That is one of my concerns - that according to the current draft only > "real" telcos can get numbers or blocks out of that range. So any VoIP > only provider just has to rely on others instead of being able to deal > with the regulator directly. right. although this is a point that shows up quite clearly, the impression i get from the current state of discussion is more the one of a swamp... it's really hard to get an idea of where it's really going in the end. that's really frustrating, while the need for a real solution grows every day, and as i said before, i don't think that non-regional national numbers are actually a real solution... > Another one is (and I find that in your proposal, too) the idea of > allocating/assigning blocks: at the end of the day we are also talking > domains here. In the domain world such a concept is totally unknown (for > good reasons!) and would not really be feaseble: get domain names > starting with a to k from registrar A and from l to z from registrar B...?! hm, right, 100% ack. but maybe that's just my bad explanation in the proposal, the idea was to allocate blocks to providers to keep administrative work at the rir level low, while every single number stays portable by using the hierarchical means provided by whois: if a single number out of the provider-allocated block is ported, the maintainer is changed to the new provider as well as the enum-delegation (see collection of 'most specific' nameserver info in the proposal). this way every number would stay portable. hmm - of course, this would spoil 'wish-numbers' (sorry for the brutal translation, corrections welcome ;), or even could lead to very very strange procedures (i'm too scared to describe what i'm thinking about ;>) by sbdy trying to get such a specific number... maybe there is a reasonable solution without allocation of blocks. in this case the rirs would probably have to deal with each single number request... i'm not sure if that can be automated or handled in a way that doesn't produce lots of work at the rir-level... maybe with some sort of assignment window? ideas more than welcome! :) > As you have to ensure portability in the long run anyways: why not > assigning a number out of such blocks (whether it's +878xx, +4932 or > something else) directly to the user? S/he can port the number to a > provider of an own choice without creating "holes" in blocks allocated > or assigned to providers/LIRs/... from my view this would be the most charming solution - but creating a lot of work on the rir level is not an option, and currently i don't know of a practical solution to that... hmm... > IMHO the difference really is that people (apart from very few ;-) do > not really care about the IP addresses they get because you hardly > announce them to third parties as points of contact anyways. But you > certainly do with your UPT/... numbers. right... hmm... maybe without allocation of blocks to providers, but allocation of a 'number of (not specific phone-)numbers' could work. actually that would already be a kind of AW-solution. hm. sounds realistic to me, while work at the rir-level were still rather low. > That, of course, would be a different registry type - more a domain > registry that an RIR. But I am certainly not saying that an RIR cannot > or even must not take up that business, too - given that all parties > involved agree to it. i think regarding the whois, it would work. the most important point is of course the last one, there of course has to be substantial consent to a general need for this. from what i see in every day business, i'd say it certainly really is there. let's find out... kind regards, Chris Heinze From enumvoipsip.cs at schiefner.de Tue Aug 10 17:26:55 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Tue, 10 Aug 2004 17:26:55 +0200 Subject: [enum-wg] UK ENUM consultation Message-ID: <4118E93F.1080700@schiefner.de> UK Department of Industry launches consultation on ENUM industry structure, among other things. [Thanks to Timonthy Denton from Canada who spotted this.] Cheers, -C. -------- Original Message -------- Subject: [nom-announce] ENUM consultation From: nominet at nominet.org.uk Date: Tue, August 10, 2004 4:01 am To: nom-announce at lists.nominet.org.uk The Department of Trade and Industry (DTI) has just launched its consultation on the proposed arrangements for UK ENUM, which will be self-regulated by the industry. ENUM is a system that links telephone numbers to Internet locations and identities such as email addresses, giving increased flexibility to electronic communications. The three main issues that the DTI are consulting on are:- * The proposed implementation of UK ENUM including the distinctions in the functions between the single Tier 1 registry and the competing Tier 2 registrars and nameserver providers * The management arrangements for UK ENUM including the formation of the UK ENUM Committee (UKEC) and the principles for the appointment of the Tier 1 registry and the terms under which the registry will be run * The arrangements for the authentication of UK ENUM entries The consultation period runs from 10 August to 10 November 2004 and further details can be found at http://www.dti.gov.uk/consultations/consultation-1230.html. The DTI will be hosting a public workshop in London on 29 September 2004 to enable more detailed discussion of the issues. The relevance to Nominet is that, in response to member requests and in accordance with agreed company strategy, we are likely to bid to become the UK Tier 1 registry. We would therefore encourage members to respond to the DTI's consultation. -- Nominet UK Announcement mailing list http://www.nominet.org.uk/lists/nom-announce.html From jim at rfc1035.com Tue Aug 10 19:07:15 2004 From: jim at rfc1035.com (Jim Reid) Date: Tue, 10 Aug 2004 18:07:15 +0100 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: Message from Chris Heinze of "Tue, 10 Aug 2004 09:54:01 +0200." <41187F19.7060900@ccn.net> Message-ID: <8613.1092157635@gromit.rfc1035.com> >>>>> "Chris" == Chris Heinze writes: Chris> can you think of a practical solution to satisfy the ITU's needs? I'm not yet sure what the requirements are: ie why you want RIPE NCC to operate some E.164 number range for UPT and why this can't be done by someone else who already has existing E.164 numbers. From an ITU perspective, I think this has to be clear before any allocation of E.164 space will be considered. In other words, you need to explain to ITU that you have a need for space -- how much?? -- that isn't or can't be addressed elsewhere. You may also need to show how this number range will interwork with the rest of the telephony world. An explanation of how other telcos and carriers can route calls to/from this number range could be helful. Bear in mind too that talk of VoIP implies telephony by-pass, which is something that makes telcos and some regulators *very* uncomfortable. Going to ITU and saying "give me a pile of E.164 numbers for VoIP so I can eliminate revenue for the telcos who pay your membership fees" isn't likely to get a warm reception. And the regulators will want to know about what will be done about access to emergency services, universal service obligations, QoS, lawful intercept, blah, blah, blah. Chris> but i also think it wasn't Chris> a bad choice for ITU to delegate tier 0 operation to RIPE. You're playing with fire here. It was IAB who delegated e164.arpa to RIPE NCC. [Not RIPE.] I believe ITU were not consulted about this and they're still a bit annoyed about that. ITU would like to be listed as the administrative contact for e164.arpa, which is another sore point. >> There would also be a conflict of interest given that RIPE NCC >> is already operating the registry for e164.arpa. So if the NCC >> was to apply for a non-geographic E.164 code and get it, this >> would probably need to be administered by a separate >> organisation from that running the e164.arpa registry. Chris> i guess it's a sub-optimal idea to allocate the block to Chris> RIPE and RIPE only, the community of RIRs probably in the Chris> form of the NRO would be a better idea, as the space is Chris> meant to be used globally. I think it would be very helpful if you could sketch out a model for how this proposed organisation would be structured and funded, what the roles & responsibilities would be, etc, etc. Bear in mind there could be legal issues too. Like the RIRs extending their monopolies or going beyond their charter obligations, impact on EU competition regulations, etc, etc. Chris> actually the work RIPE did up Chris> to now as tier 0 operator demonstrates the high Chris> qualifications of RIPE as an enum-operator at the tier 0 Chris> and tier 1 levels quite convincingly. Sure, the NCC does an excellent job at operating the Tier-0 registry. This is to be expected. However that pretty much rules them out of operating any Tier-1 (or Tier-N) infrastructure. From x at ccn.net Tue Aug 10 20:34:42 2004 From: x at ccn.net (Chris Heinze) Date: Tue, 10 Aug 2004 20:34:42 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <8613.1092157635@gromit.rfc1035.com> References: <8613.1092157635@gromit.rfc1035.com> Message-ID: <41191542.9050402@ccn.net> hi! > Chris> can you think of a practical solution to satisfy the ITU's needs? > > I'm not yet sure what the requirements are: ie why you want RIPE NCC > to operate some E.164 number range for UPT and why this can't be done > by someone else who already has existing E.164 numbers. From an ITU > perspective, I think this has to be clear before any allocation of > E.164 space will be considered. In other words, you need to explain to > ITU that you have a need for space -- how much?? -- that isn't or > can't be addressed elsewhere. ic. as explained earlier, i think the RIRs (that's not just RIPE) are a good choice as independent number coordinators in the internet. also, they - and with regard to ENUM, RIPE - have proven to be fit for such tasks. this is why the RIRs seem to be a very good choice for such an operator to me. as explained earlier, i beleive that (an)other organisation(s) could provide for the same services, but i don't see a better alternative. please feel free to suggest some. there is currently noone who holds non-geographic ENUM-enabled E.164 space available to the general public. how much numbers will be needed is an interesting question, but with no doubt such a global prefix for voip will be used by a very large community (how many voip-users do we currently have and what is the growth-rate?). > You may also need to show how this > number range will interwork with the rest of the telephony world. hm. not sure about that, in fact cc-prefixes interact really badly with the voip-rest of the telephony world... but i think this would be a process of evolution. actually i think such a number space would present a big chance for evolution and convergence. > An > explanation of how other telcos and carriers can route calls to/from > this number range could be helful. a telco could build its own ip gateways (over here i don't know of any big telco without ip, but i know of a lot of productive pstn switches that already have voip gateways build in today), or route to other telcos providing gateway services for them. calls from this number space are not a problem at all, this already works canonical for cc-numbers over here. > Bear in mind too that talk of VoIP > implies telephony by-pass, which is something that makes telcos and > some regulators *very* uncomfortable. i prefer to keep out of regulatory discussions (of course while still not being ignorant about it, but i beleive that's simply a different topic). to illustrate what i mean: i certainly won't switch to 'ipv9' because china wants to make it mandatory. i wouldn't like - and thank god i'm not forced - to be excluded from the internet because of regulations in china. the same is true in this case. if a regulator prohibits providers and/or users in a country to use global upts (i wonder why anybody should or would?), that shouldn't keep the rest of the world from using it. i guess we all know that making phonecalls on the internet doesn't depend on ENUM or E.164 number delegations. also i don't think it's a sound claim or the ITU's aim to suppress good voip solutions to keep telcos away from competition. also, my experience shows that many telcos have also discovered that voip provides interesting solutions for themselves. > Going to ITU and saying "give me > a pile of E.164 numbers for VoIP so I can eliminate revenue for the > telcos who pay your membership fees" isn't likely to get a warm > reception. well who wants that. on the other way round, do you think it would be a better idea to create a private company that sells numbers from such a space to users, to fund ITU? i think this doesn't really have a lot to do with funding of ITU. and isn't telephone number space a kind of public resource? and isn't ITU an UN organ in the end? > And the regulators will want to know about what will be > done about access to emergency services, universal service > obligations, QoS, lawful intercept, blah, blah, blah. right. all this is in discussion over here (and lots of other places, too), but thank god it didn't keep providers from providing enum-enabled voip-services and users from using them. i don't see why it should. regulations have to be followed, but i don't see why this should keep us from creating a technical means to run voip a lot more smoothly and to provide for a good means of convergence in this area. i don't see a direct connection between non-geographic enum-enabled upts and the mentioned issues, they are general voip issues. > Chris> but i also think it wasn't > Chris> a bad choice for ITU to delegate tier 0 operation to RIPE. > > You're playing with fire here. It was IAB who delegated e164.arpa to > RIPE NCC. [Not RIPE.] I believe ITU were not consulted about this and > they're still a bit annoyed about that. ITU would like to be listed as > the administrative contact for e164.arpa, which is another sore point. ...and in the end different points. i've read some letters from the ITU TSB to RIPE (NCC) and vice versa regarding an agreement on e164.arpa delegation, so i doubt that ITU wasn't involved at all, though there might have been less than perfect proceedings. but then again: i don't want to shift control or anything like that, i want to have E.164 space that is useable for voip, i.e. a global non-geographic enum-enabled prefix available to the general public. the +878 prefix is part of E.164, it is defined as non-geographic space and UPTS. E.164 is from the ITU, there seems to be some sort of consent about the need for such space in the ITU itself, and also a block has already been delegated, so it's hard for me to imagine that this idea is even something new to the ITU. actually i'm a bit surprised that there hasn't been such a proposal until now. (if you ask me, i don't see why ITU shouldn't be listed as admin-c of e164.arpa - but i think this is off-topic in this discussion.) btw: is there anybody from the ITU on this mailing list? that would be very helpful, i guess. > >> There would also be a conflict of interest given that RIPE NCC > >> is already operating the registry for e164.arpa. So if the NCC > >> was to apply for a non-geographic E.164 code and get it, this > >> would probably need to be administered by a separate > >> organisation from that running the e164.arpa registry. > > Chris> i guess it's a sub-optimal idea to allocate the block to > Chris> RIPE and RIPE only, the community of RIRs probably in the > Chris> form of the NRO would be a better idea, as the space is > Chris> meant to be used globally. > > I think it would be very helpful if you could sketch out a model for > how this proposed organisation would be structured and funded, what > the roles & responsibilities would be, etc, etc. the proposal was meant to explain that the RIRs could do the job with the means they already have developed (whois, dns, a bunch of good and working procedures with just very little adaptions), and how workload for RIRs could be reduced to a minimum to keep funding needs minimal. > Bear in mind there could be legal issues too. Like the RIRs extending > their monopolies or going beyond their charter obligations, > impact on EU competition regulations, etc, etc. the RIRs - let's simply say the NRO as the community of RIRs - are organizations to provide for coordination of number resources on the internet. looks to me like a perfect match. the RIRs are not profit-oriented organizations and are non-discriminatory. talking about a monopoly doesn't seem especially realistic in this case. but i don't want to discuss wordings, what other kind of organization could do the job in a better way? > Chris> actually the work RIPE did up > Chris> to now as tier 0 operator demonstrates the high > Chris> qualifications of RIPE as an enum-operator at the tier 0 > Chris> and tier 1 levels quite convincingly. > > Sure, the NCC does an excellent job at operating the Tier-0 > registry. This is to be expected. However that pretty much rules them > out of operating any Tier-1 (or Tier-N) infrastructure. i beleive it were a bigger benefit for voip-users and voip-providers if the RIRs operate a +878* tier1 infrastructure than the tier0 infrastructure. can you point me to the ruling that prohibits the tier0 operator from operating as tier1, too? this is certainly a point that has to be considered and i wasn't able to find info about that yet. kind regards, Chris Heinze From enumvoipsip.cs at schiefner.de Tue Aug 10 22:21:36 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Tue, 10 Aug 2004 22:21:36 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <4118CB1D.8020908@ccn.net> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <4118B448.3050808@schiefner.de> <4118CB1D.8020908@ccn.net> Message-ID: <41192E50.1040506@schiefner.de> Hi Chris, Chris Heinze wrote: >>> [currently large regional blocks are >>> reallocated by voip gateway providers to voip-users. so a voip-user >>> from e.g. dresden can have a number from e.g. duesseldorf, hamburg, >>> berlin, munich - or all of them.] >> >> [of some major concern to the regulator] > > yes - actually (except for some endusers that consider it fun to have > numbers from different cities) i know of nobody who is really happy with > this solution, you just have found the first person then. :-) My crowd back in Berlin happily rings me up with my Berlin VoIP number whereever I am. > [...] it's hardly optimal to dial > +4932.... or any other cc-number to reach a user who is currently in > helsinki and might be in hongkong tomorrow... I guess, for Germans callers it would :-) - in particular if any +4932 call from the PSTN is deemed to be local and dumped onto the Internet ASAP. And if I am able to get a grip on other CCs with similar ranges and rules, I am able to satisfy the needs of my counterparts there, too. > as an international prefix could be seen as a public resource that has > to be available in a non-discriminating way, i beleive personal numbers > assigned to the endusers are again the most straightforward solution. Indeed, you are right - at the end of the day, what I outlined above might be only a mid-term solution. Then again, you also want to be reachable from the PSTN - and as Richard Stastny said, deploying a new CC in the global PSTN seems to be really a drag... > hm, right, 100% ack. > but maybe that's just my bad explanation in the proposal, the idea was > to allocate blocks to providers to keep administrative work at the rir > level low, while every single number stays portable by using the > hierarchical means provided by whois: if a single number out of the > provider-allocated block is ported, the maintainer is changed to the new > provider as well as the enum-delegation (see collection of 'most > specific' nameserver info in the proposal). > this way every number would stay portable. So who then would be in charge of the database of ported numbers: the RIR? Many DBs, one maintained by each ITSP that got the block allocated originally? >> [ensure portability/assigning a number directly to the user] > > from my view this would be the most charming solution - but creating a > lot of work on the rir level is not an option, and currently i don't > know of a practical solution to that... hmm... On the "handling the workload" issue it might be helpful to get an opinion from an/the RIR[s] itself/themselves, I guess. > right... hmm... maybe without allocation of blocks to providers, but > allocation of a 'number of (not specific phone-)numbers' could work. > actually that would already be a kind of AW-solution. hm. sounds > realistic to me, while work at the rir-level were still rather low. I am afarid I lost you here - what do you mean with a 'number of (not specific phone-)numbers'? Even the comparision with an AW didn't help... Cheers, -C. From enumvoipsip.cs at schiefner.de Tue Aug 10 22:32:28 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Tue, 10 Aug 2004 22:32:28 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <8613.1092157635@gromit.rfc1035.com> References: <8613.1092157635@gromit.rfc1035.com> Message-ID: <411930DC.6040003@schiefner.de> Jim, Jim Reid wrote: > [...] It was IAB who delegated e164.arpa to > RIPE NCC. [Not RIPE.] there is an informational RFC about it: http://www.ietf.org/rfc/rfc3245.txt Cheers, -C. From niall.oreilly at ucd.ie Wed Aug 11 12:55:24 2004 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Wed, 11 Aug 2004 11:55:24 +0100 Subject: [enum-wg] New Subject: What ENUM wg should do... In-Reply-To: References: <6649.1092078941@gromit.rfc1035.com> Message-ID: On 9 Aug 2004, at 20:31, Patrik F?ltstr?m wrote: > One of the things Kim and I have planned for this wg is to keep a > webpage updated with, for each CC/country, answers to questions on > what rules exists for various things -- one of them being how > integration of E.164 numbers is... [ ... ] > Does this sound like a "good thing for this wg to do"? > > paf Yes, defny! Best regards, Niall O'Reilly From x at ccn.net Wed Aug 11 13:56:00 2004 From: x at ccn.net (Chris Heinze) Date: Wed, 11 Aug 2004 13:56:00 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <41192E50.1040506@schiefner.de> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <4118B448.3050808@schiefner.de> <4118CB1D.8020908@ccn.net> <41192E50.1040506@schiefner.de> Message-ID: <411A0950.9010906@ccn.net> hi! >>>> [currently large regional blocks are reallocated by voip gateway >>>> providers to voip-users. so a voip-user from e.g. dresden can have a >>>> number from e.g. duesseldorf, hamburg, berlin, munich - or all of >>>> them.] >>> >>> [of some major concern to the regulator] >> >> yes - actually (except for some endusers that consider it fun to have >> numbers from different cities) i know of nobody who is really happy >> with this solution, > > you just have found the first person then. :-) My crowd back in Berlin > happily rings me up with my Berlin VoIP number whereever I am. > >> [...] it's hardly optimal to dial +4932.... or any other cc-number to >> reach a user who is currently in helsinki and might be in hongkong >> tomorrow... > > I guess, for Germans callers it would :-) - in particular if any +4932 > call from the PSTN is deemed to be local and dumped onto the Internet ASAP. > > And if I am able to get a grip on other CCs with similar ranges and > rules, I am able to satisfy the needs of my counterparts there, too. well ok, that's the enduser-you ;) of course i'm using this too, as it's an easy way to save money. but i don't regard this as a reasonable (long-term) solution, and i strongly doubt that this practice is helpful for a reasonable development and smooth convergence... and probably this will be prohibited over here (more or less) soon, i guess this will happen in the moment +4932 becomes 'available'. btw: the enduser-you is probably less happy having to call a +1* voip-number from pstn from germany or having to call a +4932* voip-number from india compared to calling a +878* voip-number... :) telcos again might probably often be more happy with the first solution... maybe we could also set up some kind of demoscopic tool on the wg-webpage, to find out e.g. what percentage of the enum-wg resp. interested community thinks it's best or ok to stick with the cc-numbers for voip, and if so whether the regional numbers are regarded ok or only the non-regional national numbers (where available) should be used for voip? >> as an international prefix could be seen as a public resource that has >> to be available in a non-discriminating way, i beleive personal >> numbers assigned to the endusers are again the most straightforward >> solution. > > > Indeed, you are right - at the end of the day, what I outlined above > might be only a mid-term solution. Then again, you also want to be > reachable from the PSTN - and as Richard Stastny said, deploying a new > CC in the global PSTN seems to be really a drag... to illustrate better what i tried to explain before (i.e. the situation is different from a 'real' cc-prefix): imagine a telco with a PSTN network. as soon as this telco has an ip gateway (as i said before, this is already very common at least over here), the telco can route this prefix to that gateway, there an enum lookup is done and the call is connected. at the same time the telco is able but in no way forced to offer gateway services for calls from ip to pstn to voip-providers or voip-users. even if the telco doesn't have an own ip gateway, buying such a service from a different telco would be another simple option. offering connectivity to voip-numbers would be an interesting point when it comes to competition between telcos. i beleive there's a strong incentive for telcos to set up an ip gateway as soon as such a prefix is available. technically i know for example for our primary telco that it were easily possible to set up +878* routing for their PSTN network today. and no coordination with other telcos would be necessary, no dependencies. >> hm, right, 100% ack. >> but maybe that's just my bad explanation in the proposal, the idea was >> to allocate blocks to providers to keep administrative work at the rir >> level low, while every single number stays portable by using the >> hierarchical means provided by whois: if a single number out of the >> provider-allocated block is ported, the maintainer is changed to the >> new provider as well as the enum-delegation (see collection of 'most >> specific' nameserver info in the proposal). >> this way every number would stay portable. > > > So who then would be in charge of the database of ported numbers: the > RIR? Many DBs, one maintained by each ITSP that got the block allocated > originally? no, the idea is to use the whois-db. with allocated blocks these blocks would be distributed over the different RIRs' whois-dbs. porting a number would mean a change of the whois-db entry (by the current admin i.e. holder of the maintainer-object of the respective number), replacing the maintainer-object and delegation data of that entry. with assignments of single numbers without prior allocation, this is different, either some reasonable way of distributing these single assignments over the RIRs' whois-dbs must be found or a single whois-db had to be used. this also might affect the mechanism to generate delegations. only the whois-db(s) would be necessary to hold the authoritative data regarding number assignments. >>> [ensure portability/assigning a number directly to the user] >> >> >> from my view this would be the most charming solution - but creating a >> lot of work on the rir level is not an option, and currently i don't >> know of a practical solution to that... hmm... > > > On the "handling the workload" issue it might be helpful to get an > opinion from an/the RIR[s] itself/themselves, I guess. sure, that's also mentioned in the proposal. i guess you know who could be the right person with insight and ideas for procedures at the RIRs, or at least at RIPE? :) >> right... hmm... maybe without allocation of blocks to providers, but >> allocation of a 'number of (not specific phone-)numbers' could work. >> actually that would already be a kind of AW-solution. hm. sounds >> realistic to me, while work at the rir-level were still rather low. > > > I am afarid I lost you here - what do you mean with a 'number of (not > specific phone-)numbers'? Even the comparision with an AW didn't help... i mean an amount of numbers. say, a provider has the possibility to enter 1000 numbers (no matter which ones) before an application for the next e.g. 1000 numbers is necessary. i.e. still keeping an 'AW' approach while not allocating specific blocks. kind regards, Chris Heinze From enumvoipsip.cs at schiefner.de Wed Aug 11 16:59:00 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Wed, 11 Aug 2004 16:59:00 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <411A0950.9010906@ccn.net> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <4118B448.3050808@schiefner.de> <4118CB1D.8020908@ccn.net> <41192E50.1040506@schiefner.de> <411A0950.9010906@ccn.net> Message-ID: <411A3434.3060509@schiefner.de> Hi, Chris. Chris Heinze wrote: > [...] > even if the telco doesn't have an own ip gateway, buying such a service > from a different telco would be another simple option. That's pretty much an European view. What about countries where there is only the incumbent around? Why (no competition!) should they dump it onto the net ASAP (and loose revenue) instead of making it a long distance/intercont call? If they route the call at all... I believe even after a full introduction of +878 we will have those two types of VoIP numbers around for quite a while. > no, the idea is to use the whois-db. with allocated blocks these blocks > would be distributed over the different RIRs' whois-dbs. porting a > number would mean a change of the whois-db entry (by the current admin > i.e. holder of the maintainer-object of the respective number), > replacing the maintainer-object and delegation data of that entry. > > with assignments of single numbers without prior allocation, this is > different, either some reasonable way of distributing these single > assignments over the RIRs' whois-dbs must be found or a single whois-db > had to be used. this also might affect the mechanism to generate > delegations. > > only the whois-db(s) would be necessary to hold the authoritative data > regarding number assignments. Maybe you lost me here again: wouldn't that mean that over time, when people continue to port their numbers as they like, you'll end up with an entry per number? Then you should consider having such an implementation already from the very begining. And you have something that is pretty similar to a [domain] name registry... >> On the "handling the workload" issue it might be helpful to get an >> opinion from an/the RIR[s] itself/themselves, I guess. > > sure, that's also mentioned in the proposal. i guess you know who could > be the right person with insight and ideas for procedures at the RIRs, > or at least at RIPE? :) That indeed could be the case, yes. ;-) However, I will certainly refrain from pointing folks out here. > i mean an amount of numbers. say, a provider has the possibility to > enter 1000 numbers (no matter which ones) before an application for the > next e.g. 1000 numbers is necessary. > i.e. still keeping an 'AW' approach while not allocating specific blocks. And why would this be useful? The 'AW' approach IMHO originates from the demand to have some greater flexibility on the LIR's side when doing assignments - while still keeping the idea of conservation. Question is: is there a more or less identical need for this type of conservation for UPT numbers, too? Or isn't it more like a one-off? At the end of the day it's "personal" - apart from some exceptions here and there: why would people liek to have more than one? Cheers, -C. From richard at shockey.us Wed Aug 11 17:10:06 2004 From: richard at shockey.us (Richard Shockey) Date: Wed, 11 Aug 2004 11:10:06 -0400 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <06CF906FE3998C4E944213062009F162443845@oefeg-s02.oefeg.loc > References: <06CF906FE3998C4E944213062009F162443845@oefeg-s02.oefeg.loc> Message-ID: <6.1.0.6.2.20040811110736.03bd6640@joy.songbird.com> A > >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. > > 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. Which is exactly the way the US and Canada works but we have have a flat numbering space which means you can take your wire line and port to wireless as well. Patrik remind me .. does Sweden use a Database model or is it simply call forwarding form the originating carriers Switch . > > 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 > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From richard at shockey.us Wed Aug 11 17:15:45 2004 From: richard at shockey.us (Richard Shockey) Date: Wed, 11 Aug 2004 11:15:45 -0400 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <4118789F.2000505@ccn.net> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> Message-ID: <6.1.0.6.2.20040811111120.03d61260@joy.songbird.com> A > > My point is not that your idea is wrong, but that you have to take > > into account a number of different issues... > >certainly. i hope this is the right place for a discussion for these >issues, and for finding good solutions for identified problems. :) > > > Can you be more specific on what the rules are for E.164 numbers in > > your neck of the woods? > >that's germany. +49 numbers are in their regions fully portable between >pstn providers. currently large regional blocks are reallocated by voip >gateway providers to voip-users. so a voip-user from e.g. dresden can have >a number from e.g. duesseldorf, hamburg, berlin, munich - or all of them. >that's really ugly but voip providers actually have no big choice. there >is a 'region' reserved for non-regional (in the end of course still >national) numbers (+4932), but this is currently discussed and it's >unlikely that this prefix will be useably anytime soon. also, there are >strong doubts that this prefix will be freely available to voip-providers, >the current discussion shows that there will probably be dependencies and >drawbacks especially for voip. Ah ..just like the US. We hear lots of barking by the US State Govt ( aka your Lander) on the allocation of "their numbers" by Vonage to out of region customers but the truth is there is nothing they can do about it. We're recovering so many phone numbers now from the system no one cares how they get allocated any more. I'm pretty sure I'll live to see Geographic portability in the US. Its technically its a trivial exercise. >kind regards, > > Chris Heinze >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From richard at shockey.us Wed Aug 11 17:05:25 2004 From: richard at shockey.us (Richard Shockey) Date: Wed, 11 Aug 2004 11:05:25 -0400 Subject: [enum-wg] New Subject: What ENUM wg should do... In-Reply-To: <6742.1092081049@gromit.rfc1035.com> References: <6742.1092081049@gromit.rfc1035.com> Message-ID: <6.1.0.6.2.20040811110436.042d00e0@joy.songbird.com> At 03:50 PM 8/9/2004, Jim Reid wrote: > >>>>> "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= writes: > > paf> One of the things Kim and I have planned for this wg is to > paf> keep a webpage updated with, for each CC/country, answers to > paf> questions on what rules exists for various things -- one of > paf> them being how integration of E.164 numbers is... > > paf> Does this sound like a "good thing for this wg to do"? > >YES! Yep .. and add URI's for the various national ENUM Fourm's etc. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From x at ccn.net Wed Aug 11 17:50:35 2004 From: x at ccn.net (Chris Heinze) Date: Wed, 11 Aug 2004 17:50:35 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <411A3434.3060509@schiefner.de> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <4118B448.3050808@schiefner.de> <4118CB1D.8020908@ccn.net> <41192E50.1040506@schiefner.de> <411A0950.9010906@ccn.net> <411A3434.3060509@schiefner.de> Message-ID: <411A404B.3080604@ccn.net> hi! >> [...] >> even if the telco doesn't have an own ip gateway, buying such a >> service from a different telco would be another simple option. > > > That's pretty much an European view. What about countries where there is > only the incumbent around? Why (no competition!) should they dump it > onto the net ASAP (and loose revenue) instead of making it a long > distance/intercont call? If they route the call at all... well that's a question for the regulator then, isn't it. i don't want to nor see a reason why to mess with regulations. if a country decides to ban voip-gateways (although still i don't really know a good reason why), that's the country's decision and that decision has to be followed in that country. but i don't think this is a good reason to prevent everyone else from promoting voip. > I believe even after a full introduction of +878 we will have those two > types of VoIP numbers around for quite a while. probably. certainly this cannot be avoided for a long time (except locally by regulators), but also i'm not the one who demands that this has to be avoided. >> no, the idea is to use the whois-db. with allocated blocks these >> blocks would be distributed over the different RIRs' whois-dbs. >> porting a number would mean a change of the whois-db entry (by the >> current admin i.e. holder of the maintainer-object of the respective >> number), replacing the maintainer-object and delegation data of that >> entry. >> >> with assignments of single numbers without prior allocation, this is >> different, either some reasonable way of distributing these single >> assignments over the RIRs' whois-dbs must be found or a single >> whois-db had to be used. this also might affect the mechanism to >> generate delegations. >> >> only the whois-db(s) would be necessary to hold the authoritative data >> regarding number assignments. > > > Maybe you lost me here again: wouldn't that mean that over time, when > people continue to port their numbers as they like, you'll end up with > an entry per number? Then you should consider having such an > implementation already from the very begining. And you have something > that is pretty similar to a [domain] name registry... right. actually in the proposal any assigned number (or assigned block) is a single entry right from the beginning. i just checked the text (3.2), and it's in fact not clearly stated. the idea was to enter every assignment as a new object into the whois-db at the time when assignment is done. i also regard it as quite similar to a domain registry (and in other respects similar to an ip registry). >>> On the "handling the workload" issue it might be helpful to get an >>> opinion from an/the RIR[s] itself/themselves, I guess. >> >> >> sure, that's also mentioned in the proposal. i guess you know who >> could be the right person with insight and ideas for procedures at the >> RIRs, or at least at RIPE? :) > > > That indeed could be the case, yes. ;-) However, I will certainly > refrain from pointing folks out here. sure, just send them here if they don't run away fast enough ;) >> i mean an amount of numbers. say, a provider has the possibility to >> enter 1000 numbers (no matter which ones) before an application for >> the next e.g. 1000 numbers is necessary. >> i.e. still keeping an 'AW' approach while not allocating specific blocks. > > > And why would this be useful? The 'AW' approach IMHO originates from the > demand to have some greater flexibility on the LIR's side when doing > assignments - while still keeping the idea of conservation. > > Question is: is there a more or less identical need for this type of > conservation for UPT numbers, too? Or isn't it more like a one-off? At > the end of the day it's "personal" - apart from some exceptions here > and there: why would people liek to have more than one? the concept as such should work also without an 'assignment window'. but i think it's not a too bad idea, otherwise most-popular-vanity-number grabbing probably can not be prevented. also, depending on the policy, conservation might be identified as an issue. kind regards, Chris Heinze From paf at cisco.com Wed Aug 11 18:04:46 2004 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Wed, 11 Aug 2004 18:04:46 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <6.1.0.6.2.20040811110736.03bd6640@joy.songbird.com> References: <06CF906FE3998C4E944213062009F162443845@oefeg-s02.oefeg.loc> <6.1.0.6.2.20040811110736.03bd6640@joy.songbird.com> Message-ID: <2A4B3832-EBB0-11D8-8018-000A95B2B926@cisco.com> On Aug 11, 2004, at 17:10, Richard Shockey wrote: > Patrik remind me .. does Sweden use a Database model or is it simply > call forwarding form the originating carriers Switch . A shared database model. paf From enumvoipsip.cs at schiefner.de Wed Aug 11 19:04:43 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Wed, 11 Aug 2004 19:04:43 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <6.1.0.6.2.20040811111120.03d61260@joy.songbird.com> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <6.1.0.6.2.20040811111120.03d61260@joy.songbird.com> Message-ID: <411A51AB.8060904@schiefner.de> Richard, Richard Shockey wrote: > [...] > > I'm pretty sure I'll live to see Geographic portability in the US. Its > technically its a trivial exercise. humm... sure? Not about the technical part, certainly - but about your assumptions in regards of the flexibility and ability to move when it comes to regulators and the like. I recently during a VoIP round-table raised that very questions to a rep from RegTP, the German regulator, whether in the wake of the +49.32 deliberations there are any first thoughts to get rid of area specific codes, i.e. enable geographic portability. The answer was a clear "No, nothing whatsoever". Later on, during a privat chat, I heard something like "It's still partly used for PSTN routing and also important for tariffing" - humm... And a really heretic thought: what about phone numbers becoming a commodity sometime in the future, as in: fully portable on a global scale? Cheers, -C. From richard at shockey.us Wed Aug 11 19:19:24 2004 From: richard at shockey.us (Richard Shockey) Date: Wed, 11 Aug 2004 13:19:24 -0400 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <411A51AB.8060904@schiefner.de> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <6.1.0.6.2.20040811111120.03d61260@joy.songbird.com> <411A51AB.8060904@schiefner.de> Message-ID: <6.1.0.6.2.20040811131411.03e7bec0@joy.songbird.com> At 01:04 PM 8/11/2004, Carsten Schiefner wrote: >Richard, > >Richard Shockey wrote: >>[...] >>I'm pretty sure I'll live to see Geographic portability in the US. Its >>technically its a trivial exercise. > >humm... sure? Not about the technical part, certainly - but about your >assumptions in regards of the flexibility and ability to move when it >comes to regulators and the like. Exactly .. but Wireless and VoIP are breaking down those barriers in the eyes of consumers so the questions are being asked in addition if you were a marketing director for a Incumbent land line Carrier looking how to keep your customer base ..its a tool you dont have now. Or as a eloquent New Yorker would put it " What the Fxxx do you mean I have to change my Fxxxxxx number. I'm moving from West 46th to West 82 you Fxxxxx moron!!" "I can get a cell phone and they will port the Fxxxxxx number!" >I recently during a VoIP round-table raised that very questions to a rep >from RegTP, the German regulator, whether in the wake of the +49.32 >deliberations there are any first thoughts to get rid of area specific >codes, i.e. enable geographic portability. The answer was a clear "No, >nothing whatsoever". I imagine the silence was deafening. I can just see the little DT reps desperately trying to get the subject changed as fast a possible. " isnt it lunch time yet?" >Later on, during a privat chat, I heard something like "It's still partly >used for PSTN routing and also important for tariffing" - humm... PRECISELY .. the only justification for geographic codes is the artificial barriers of "rate centers" used for Tariffs Something your friendly national incumbent monopoly carrier does not want to talk about especially in front of regulators. >And a really heretic thought: what about phone numbers becoming a >commodity sometime in the future, as in: fully portable on a global scale? I think we'll all just dial via SIP URI before we see that happen >Cheers, > > -C. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141 at fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From x at ccn.net Wed Aug 11 19:39:25 2004 From: x at ccn.net (Chris Heinze) Date: Wed, 11 Aug 2004 19:39:25 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <6.1.0.6.2.20040811131411.03e7bec0@joy.songbird.com> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <6.1.0.6.2.20040811111120.03d61260@joy.songbird.com> <411A51AB.8060904@schiefner.de> <6.1.0.6.2.20040811131411.03e7bec0@joy.songbird.com> Message-ID: <411A59CD.2020507@ccn.net> hi! >> And a really heretic thought: what about phone numbers becoming a >> commodity sometime in the future, as in: fully portable on a global >> scale? > > > I think we'll all just dial via SIP URI before we see that happen hmmm - well if there were a global non-geographic e.164 space available... ;) kind regards, Chris Heinze From niall.oreilly at ucd.ie Wed Aug 11 20:02:49 2004 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Wed, 11 Aug 2004 19:02:49 +0100 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <411A51AB.8060904@schiefner.de> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <6.1.0.6.2.20040811111120.03d61260@joy.songbird.com> <411A51AB.8060904@schiefner.de> Message-ID: On 11 Aug 2004, at 18:04, Carsten Schiefner wrote: > I heard something like "It's still partly used for PSTN routing I suppose in a large country there has to be a large amount of surviving legacy technology and provisioning procedures. > and also important for tariffing" That's disappointing. Legacy tariffing suggests the relevant regulator is giving the incumbent too much slack. I wonder how the arrival of small, go-ahead "accession countries" will shake this status quo. Best regards, Niall O'Reilly From enumvoipsip.cs at schiefner.de Wed Aug 11 20:04:36 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Wed, 11 Aug 2004 20:04:36 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <411A404B.3080604@ccn.net> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <4118B448.3050808@schiefner.de> <4118CB1D.8020908@ccn.net> <41192E50.1040506@schiefner.de> <411A0950.9010906@ccn.net> <411A3434.3060509@schiefner.de> <411A404B.3080604@ccn.net> Message-ID: <411A5FB4.4090601@schiefner.de> Hi. Chris Heinze wrote: >> [If the incumbent routes the call at all...] > > well that's a question for the regulator then, isn't it. ...which in various countries IS the incumbent. > i don't want to > nor see a reason why to mess with regulations. if a country decides to > ban voip-gateways (although still i don't really know a good reason > why), Keep the minute meters of the 100% state owned telco glooming, for example? There has been precedence set in Belorussia AFAIR where two people went to jail for a considerable period of time for using VoIP. Interestingly, there was no law whatsoever prohibiting VoIP. The charge was something along the lines of "causing revenue loss to the incumbent". > that's the country's decision and that decision has to be followed > in that country. but i don't think this is a good reason to prevent > everyone else from promoting voip. That indeed is true. :-) > the concept as such should work also without an 'assignment window'. but > i think it's not a too bad idea, otherwise most-popular-vanity-number > grabbing probably can not be prevented. So? Why should it? If it's FCFS and I am faster that you, why shouldn't I get the most attractive number and you only the second most? Or vice-versa, of course! ;-) Secondly: is an AW-type of measure really the appropriate means to deal with this very issue? > also, depending on the policy, > conservation might be identified as an issue. Coudl you further detail here? The only reason for depletion I can see is rather natural: a massive interest by individuals. As said already: I have hard times thinking about individuals who would like to have MORE than one number - isn't the whole exercise about subsuming various means of communication under ONE number?! ;-) Cheers, -C. From enumvoipsip.cs at schiefner.de Wed Aug 11 21:38:13 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Wed, 11 Aug 2004 21:38:13 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <6.1.0.6.2.20040811131411.03e7bec0@joy.songbird.com> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <6.1.0.6.2.20040811111120.03d61260@joy.songbird.com> <411A51AB.8060904@schiefner.de> <6.1.0.6.2.20040811131411.03e7bec0@joy.songbird.com> Message-ID: <411A75A5.60000@schiefner.de> Richard Shockey wrote: >> I recently during a VoIP round-table raised that very questions to a >> rep from RegTP, the German regulator, whether in the wake of the >> +49.32 deliberations there are any first thoughts to get rid of area >> specific codes, i.e. enable geographic portability. The answer was a >> clear "No, nothing whatsoever". > > I imagine the silence was deafening. I can just see the little DT reps > desperately trying to get the subject changed as fast a possible. " isnt > it lunch time yet?" Actually not. There was no DT rep on the stage at least - and the people there had no real ears for numbering issues in general (apart from bashing the lenghy process for +49.32), but were most concerned about DT's strong (> 90%) position in the DSL market, the lack of technical alternatives to it - such as cable - and insufficient LLU: you still have to get a PSTN (no damn mercy!) line if you want to have DT-based DSL. Even via a third party reseller... >> Later on, during a privat chat, I heard something like "It's still >> partly used for PSTN routing and also important for tariffing" - humm... > > PRECISELY .. the only justification for geographic codes is the > artificial barriers of "rate centers" used for Tariffs Something your > friendly national incumbent monopoly carrier does not want to talk about > especially in front of regulators. It was actually a rep from the regulator pointing that out. When I mentioned that there are carriers around already offering calls to any destination within the borders of the Federal Republic for 1.x cents a minute,so tariffing might not be a viable argument in the long run any longer - then I felt that deafening silence... >> And a really heretic thought: what about phone numbers becoming a >> commodity sometime in the future, as in: fully portable on a global >> scale? > > I think we'll all just dial via SIP URI before we see that happen Or this way, yes... ;-) Cheers, -C. From enumvoipsip.cs at schiefner.de Wed Aug 11 21:39:10 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Wed, 11 Aug 2004 21:39:10 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <411A59CD.2020507@ccn.net> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <6.1.0.6.2.20040811111120.03d61260@joy.songbird.com> <411A51AB.8060904@schiefner.de> <6.1.0.6.2.20040811131411.03e7bec0@joy.songbird.com> <411A59CD.2020507@ccn.net> Message-ID: <411A75DE.5030804@schiefner.de> Chris Heinze wrote: >> I think we'll all just dial via SIP URI before we see that happen > > hmmm - well if there were a global non-geographic e.164 space > available... ;) Sticking to your point, huh? ;-) Right so... -C. From enumvoipsip.cs at schiefner.de Wed Aug 11 21:40:41 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Wed, 11 Aug 2004 21:40:41 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <6.1.0.6.2.20040811111120.03d61260@joy.songbird.com> <411A51AB.8060904@schiefner.de> Message-ID: <411A7639.5040207@schiefner.de> Niall O'Reilly wrote: > I wonder how the arrival of small, go-ahead "accession countries" will > shake > this status quo. I'll allow myself to be pleasantly surprised... :-) -C. From x at ccn.net Thu Aug 12 11:59:14 2004 From: x at ccn.net (Chris Heinze) Date: Thu, 12 Aug 2004 11:59:14 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <411A5FB4.4090601@schiefner.de> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <4118B448.3050808@schiefner.de> <4118CB1D.8020908@ccn.net> <41192E50.1040506@schiefner.de> <411A0950.9010906@ccn.net> <411A3434.3060509@schiefner.de> <411A404B.3080604@ccn.net> <411A5FB4.4090601@schiefner.de> Message-ID: <411B3F72.1000702@ccn.net> hi! >>> [If the incumbent routes the call at all...] >> >> >> well that's a question for the regulator then, isn't it. > > > ...which in various countries IS the incumbent. if the legislator wants such a situation and in this course decides or lets the incumbent decide to suppress voip, that's a local regulation issue, i beleive. i myself regard it - even in the case of a state pstn monopoly - as a not especially brilliant idea to prevent voip development, and also maybe they're all just waiting for global number space... ;) >> i don't want to nor see a reason why to mess with regulations. if a >> country decides to ban voip-gateways (although still i don't really >> know a good reason why), > > > Keep the minute meters of the 100% state owned telco glooming, for > example? you really regard this as a _good_ reason? ;) >> the concept as such should work also without an 'assignment window'. >> but i think it's not a too bad idea, otherwise >> most-popular-vanity-number grabbing probably can not be prevented. > > > So? Why should it? If it's FCFS and I am faster that you, why shouldn't > I get the most attractive number and you only the second most? Or > vice-versa, of course! ;-) well this principle (first come first serve) is certainly ok and i generally support it. but imagine, without a means like the AW and with an automated process, i just start a script and assign, let's say, the 10000 most popular numbers like 1111..., 2222..., 3333..., 1234..., 8787... to myself to park them, and then sell them. or i don't need to sell them, i just advertise them on my webpage as a nice add-on for people that become my customers... (i personally wouldn't mind too much, because i have no big interest in special numbers, i certainly wouldn't choose a provider because of the numbers i can get there, but i assumed (keeping in mind that there are people who like to have a special number) that people might find this unfair - but i might be wrong. i don't know.) i think as a policy issue this certainly is an issue that should be discussed with as broad participation from the interested community as possible. should number-grabbing be forbidden by policy? if so, is a means of limitation/supervision/enforcement necessary? or should the policy generally allow for only exactly one one-number assignment per person? if so, per natural person only? if not, only one one-number assignment per organisation? other ideas? > Secondly: is an AW-type of measure really the appropriate means to deal > with this very issue? assuming a general consent that a means of limitation of unsupervised automated assignments is necessary or desirable, i think it is a helping means (otherwise it's probably superfluous). until now no better means came to my mind. suggestions more than welcome! if it turned out to be superfluous that would of course be great, as it would further minimize work that couldn't be done by scripts, and also simplify procedures. >> also, depending on the policy, conservation might be identified as an >> issue. > > > Coudl you further detail here? The only reason for depletion I can see > is rather natural: a massive interest by individuals. As said already: I > have hard times thinking about individuals who would like to have MORE > than one number - isn't the whole exercise about subsuming various means > of communication under ONE number?! ;-) you're probabl right here. what i wanted to say is that as there's naturally no policy yet, i don't want to say that there might not just pop up some other issues that require a slow-start-mechanism or means of 'dampening' or something like that. kind regards, Chris Heinze From enumvoipsip.cs at schiefner.de Wed Aug 18 13:15:06 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Wed, 18 Aug 2004 13:15:06 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <411B3F72.1000702@ccn.net> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <4118B448.3050808@schiefner.de> <4118CB1D.8020908@ccn.net> <41192E50.1040506@schiefner.de> <411A0950.9010906@ccn.net> <411A3434.3060509@schiefner.de> <411A404B.3080604@ccn.net> <411A5FB4.4090601@schiefner.de> <411B3F72.1000702@ccn.net> Message-ID: <41233A3A.4020803@schiefner.de> Hi, Chris Heinze wrote: >> Keep the minute meters of the 100% state owned telco glooming, for >> example? > > you really regard this as a _good_ reason? ;) depends on the PoV, I'd say. Being such a telco, keeping VoIP out of my business has not only a good, but even numerous excelllent reasons for. ;-) > i think as a policy issue this certainly is an issue that should be > discussed with as broad participation from the interested community as > possible. Sure - that is what we are doing here right now, huh? ;-) Although I still feel a slight lack of "broad participation from the interested community"... > should number-grabbing be forbidden by policy? if so, is a means of > limitation/supervision/enforcement necessary? > > or should the policy generally allow for only exactly one one-number > assignment per person? if so, per natural person only? if not, only one > one-number assignment per organisation? other ideas? What we always would need to bear in mind is: a) Is the aim of the policy really necessary? What is likely to happen if there is no policy in this regard? b) Is the measures of the policy likely to fulfil its aims? c) Is the application of a certain policy feasible for the entity supposed to apply it? What if it fails partly or even in general? Has the application of such policy any side effects, in particular unwanted ones? Best, -C. From x at ccn.net Thu Aug 19 15:23:27 2004 From: x at ccn.net (Chris Heinze) Date: Thu, 19 Aug 2004 15:23:27 +0200 Subject: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public In-Reply-To: <41233A3A.4020803@schiefner.de> References: <41178FE4.2090802@ccn.net> <762BF988-EA32-11D8-BA68-000A95B2B926@cisco.com> <4118789F.2000505@ccn.net> <4118B448.3050808@schiefner.de> <4118CB1D.8020908@ccn.net> <41192E50.1040506@schiefner.de> <411A0950.9010906@ccn.net> <411A3434.3060509@schiefner.de> <411A404B.3080604@ccn.net> <411A5FB4.4090601@schiefner.de> <411B3F72.1000702@ccn.net> <41233A3A.4020803@schiefner.de> Message-ID: <4124A9CF.9050000@ccn.net> hi! >>> Keep the minute meters of the 100% state owned telco glooming, for >>> example? >> >> >> you really regard this as a _good_ reason? ;) > > > depends on the PoV, I'd say. Being such a telco, keeping VoIP out of my > business has not only a good, but even numerous excelllent reasons for. ;-) well in this case i can tell you really great reasons why everybody who wants to get any telephone number has to pay me 1EUR. :> not valid, i'd say. this is a community forum, a collaborative forum, i think the reason 'because this way i can become richer faster without having to deal with competition' doesn't count too much in this context... at least i'm convinced that it shouldn't ;) >> i think as a policy issue this certainly is an issue that should be >> discussed with as broad participation from the interested community as >> possible. > > > Sure - that is what we are doing here right now, huh? ;-) Although I > still feel a slight lack of "broad participation from the interested > community"... right. patrick, can you tell us how many subscribers are currently on this list? i also received some mail regarding this discussion, i can just again ask everyone to take part in the public discussion here on the mailinglist, that's really much more effective than direct email only. >> should number-grabbing be forbidden by policy? if so, is a means of >> limitation/supervision/enforcement necessary? >> >> or should the policy generally allow for only exactly one one-number >> assignment per person? if so, per natural person only? if not, only >> one one-number assignment per organisation? other ideas? > > > What we always would need to bear in mind is: > a) Is the aim of the policy really necessary? What is likely to happen > if there is no policy in this regard? right. i'm convinced if there's no limitation at all, number grabbing on a large scale will occur. usually, what can be done will be done, i.e. i regard it as probable that there will happen things like considerable part of the space (or maybe even half of or the whole space) being parked by a single or a few organisations. therefore i'd propose that this should at least be mentioned in the policies, something like the ip policy, so that assignments are only to be made if there's actually reasonable need by an enduser to actually use the number(s) to be assigned. i don't (yet?) see a necessity for a general limitation of one number per person, and i see a potential problem with companies limited to one number (and i doubt that such demands can be broken down to natural persons), so for these reasons i'd suggest not to create such a fixed limit. > b) Is the measures of the policy likely to fulfil its aims? i'm not sure whether such a policy needs a means of enforcement, esp. when human interaction by the registry has to be avoided (for cost reasons). i personally would like to discuss this more before coming to a conclusion for myself (any 'ripe-services insider' here who can comment on the workload usually created by a new lir 'without aw' compared to 'with aw'? is there generally reliable discipline of sticking to the policies by the lirs themselves, even without a special means of enforcement?). > c) Is the application of a certain policy feasible for the entity > supposed to apply it? What if it fails partly or even in general? Has > the application of such policy any side effects, in particular > unwanted ones? well ok i kind of referred to that above. in case there should be a policy denying parking of assignments, i'd currently suggest to start with a slow-start-mechanism (e.g. aw), and evaluate the experiences after some while, whether such a mechanism turned out to be useful or unnecessary. btw: anyone interested in a workshop on this topic? kind regards, Chris Heinze From x at ccn.net Fri Aug 20 17:10:01 2004 From: x at ccn.net (Chris Heinze) Date: Fri, 20 Aug 2004 17:10:01 +0200 Subject: [enum-wg] .de regulator starts proceeding against voip providers using +49 numbers for voip Message-ID: <41261449.40108@ccn.net> hi! seems like regtp (.de regulator) starts to proceed against voip providers using +49 numbers for voip. a german article: http://golem.de/0408/33112.html basically the article says that regtp approached two of the more-well-known voip providers in germany and ordered them to stop using +49 numbers for voip users that 'are not located in the region of the number' (i.e. a 'user from duesseldorf' (i have no information on what regtp thinks that means) is not allowed to get a number from hamburg). the german non-regional prefix is currently still not available. so basically that means that german voip providers cannot use +49 numbers anymore. a non-german gateway or gateway-provider might help - sorry carsten, your folks might soon have to dial a foreign-cc-number to reach you from pstn via voip... i beleive the two providers are present here - if so, any further comments/info from that side would of course be more than interesting... :) kind regards, Chris Heinze From paf at cisco.com Fri Aug 20 17:35:49 2004 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Fri, 20 Aug 2004 08:35:49 -0700 Subject: [enum-wg] .de regulator starts proceeding against voip providers using +49 numbers for voip In-Reply-To: <41261449.40108@ccn.net> References: <41261449.40108@ccn.net> Message-ID: <9CA8FC2E-F2BE-11D8-907B-000A95B2B926@cisco.com> I would like a comment from people in germany whether the same rules exists for enterprise-based TDM-based PBX:es where a company (based in Frankfurt for example) have numbers one can dial direct which is located outside of Frankfurt. If you don't know, please ask someone. I.e. what I have found is that these "rules" which exists in the "traditional world" are violated already now in many many cases, and I am kind of concerned that a provider have to follow so many rules when IP is carrier when they don't have to if traditional telephony is in use. paf On Aug 20, 2004, at 08:10, Chris Heinze wrote: > hi! > > seems like regtp (.de regulator) starts to proceed against voip > providers using +49 numbers for voip. > > a german article: > http://golem.de/0408/33112.html > > basically the article says that regtp approached two of the > more-well-known voip providers in germany and ordered them to stop > using +49 numbers for voip users that 'are not located in the region > of the number' (i.e. a 'user from duesseldorf' (i have no information > on what regtp thinks that means) is not allowed to get a number from > hamburg). > > the german non-regional prefix is currently still not available. so > basically that means that german voip providers cannot use +49 numbers > anymore. a non-german gateway or gateway-provider might help - sorry > carsten, your folks might soon have to dial a foreign-cc-number to > reach you from pstn via voip... > > i beleive the two providers are present here - if so, any further > comments/info from that side would of course be more than > interesting... :) > > kind regards, > > Chris Heinze > From enumvoipsip.cs at schiefner.de Fri Aug 20 18:31:49 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Fri, 20 Aug 2004 18:31:49 +0200 Subject: [enum-wg] .de regulator starts proceeding against voip providers using +49 numbers for voip In-Reply-To: <9CA8FC2E-F2BE-11D8-907B-000A95B2B926@cisco.com> References: <41261449.40108@ccn.net> <9CA8FC2E-F2BE-11D8-907B-000A95B2B926@cisco.com> Message-ID: <41262775.7050004@schiefner.de> Patrik, Patrik F?ltstr?m wrote: > I would like a comment from people in germany whether the same rules > exists for enterprise-based TDM-based PBX:es where a company (based in > Frankfurt for example) have numbers one can dial direct which is located > outside of Frankfurt. > > If you don't know, please ask someone. I guess Chris and I can pick that up. Me too, I know of at least one geographic number for customer support services whose termination follows the sun around the globe... The difference, however, in these cases might be that the subscriber (aka. the company) indeed is legally established there. And that appears to be exactly what RegTP is requiring right now: you need to be a resident of the area the respective area code is assigned to. Then you are fine to use the number regardless where you are - apparently. I'll check for the legal basis for this order - that should lead to some clarity... RegTP's press release is available in German at: http://www.regtp.de/aktuelles/pm/03044/index.html - it is hopefully also accessible in English soon via: http://www.regtp.de/en/aktuelles/start/fs_03.html Cheers, -C. From paf at cisco.com Fri Aug 20 18:50:25 2004 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Fri, 20 Aug 2004 09:50:25 -0700 Subject: [enum-wg] .de regulator starts proceeding against voip providers using +49 numbers for voip In-Reply-To: <41262775.7050004@schiefner.de> References: <41261449.40108@ccn.net> <9CA8FC2E-F2BE-11D8-907B-000A95B2B926@cisco.com> <41262775.7050004@schiefner.de> Message-ID: <08A02D4A-F2C9-11D8-907B-000A95B2B926@cisco.com> On Aug 20, 2004, at 09:31, Carsten Schiefner wrote: > The difference, however, in these cases might be that the subscriber > (aka. the company) indeed is legally established there. And that > appears to be exactly what RegTP is requiring right now: you need to > be a resident of the area the respective area code is assigned to. > Then you are fine to use the number regardless where you are - > apparently. Aha, that is something different from what I read in the original message. paf From enumvoipsip.cs at schiefner.de Sat Aug 21 13:15:32 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Sat, 21 Aug 2004 13:15:32 +0200 Subject: [enum-wg] .de regulator starts proceeding against voip providers using +49 numbers for voip In-Reply-To: <08A02D4A-F2C9-11D8-907B-000A95B2B926@cisco.com> References: <41261449.40108@ccn.net> <9CA8FC2E-F2BE-11D8-907B-000A95B2B926@cisco.com> <41262775.7050004@schiefner.de> <08A02D4A-F2C9-11D8-907B-000A95B2B926@cisco.com> Message-ID: <41272ED4.60805@schiefner.de> Hi Patrik, Patrik F?ltstr?m wrote: >On Aug 20, 2004, at 09:31, Carsten Schiefner wrote: >> The difference, however, in these cases might be that the subscriber >> (aka. the company) indeed is legally established there. And that >> appears to be exactly what RegTP is requiring right now: you need to >> be a resident of the area the respective area code is assigned to. >> Then you are fine to use the number regardless where you are - >> apparently. > > Aha, that is something different from what I read in the original message. However, as I have learned in the meantime, Deutsche Telekom is offering a PSTN product called "T-Net vor Ort" (roughly: T-Net on-site) where a customer located in area A can get an area B number rerouted to his area A number - which appears to be pretty much what sipgate et al. are doing. Stay tuned, -C. From Richard.Stastny at oefeg.at Sat Aug 21 18:28:15 2004 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Sat, 21 Aug 2004 18:28:15 +0200 Subject: [enum-wg] .de regulator starts proceeding against voip providers using +49 numbers for voip Message-ID: <06CF906FE3998C4E944213062009F16244384B@oefeg-s02.oefeg.loc> Carsten wrote: >However, as I have learned in the meantime, Deutsche Telekom is offering >a PSTN product called "T-Net vor Ort" (roughly: T-Net on-site) where a >customer located in area A can get an area B number rerouted to his area >A number - which appears to be pretty much what sipgate et al. are doing. In Austria we have have this feature (although not very well known to to customers - like many ISDN features) since more then 20 years. It is simple: you get a number in an office without an attached physical line and simply put a Call Forwarding Unconditional (CFU) on it. Companies used this for routing local calls to their call centers located somewhere else before 0800 was introduced, so you see how old this feature is. Note however: you CANNOT originate calls using this number This will be important! Nobody had any problem with this, but again: "Quod licet Jovi, non licet bovi" Back to the original dicussion: What are the problems with geographic numbers for VoIP? Since we have the same dicussion here in Austria too, some of the arguments: pro and contra But first some philosphical ideas about E.164 numbers: - an E.164 number is primarily an address(name) for a destination (end-point), in principle you do not need an E.164 number to originate a call (but see below), in the same way you do not need an address to post a letter. - you need an address for posting a letter only to identify youself and to provide a return address, same is valid for phone calls. -with originating phone calls you need an E.164 number only to provide call back CLI, identification (MCI) and geographic address for emergency calls (we will see later that this is an important argument) 1) A geographic number is giving you the approx location of the recipient This may be interesting for calling Pizza services, but with call forwardings and mobile phones this arguement does not hold. Note: there is of course a difference between NA an EU. In Europe most mobile numbers are different to geographic numbers, in NA all mobile numbers are also geogrphic. 2) a geographic number gives others the possibility to call you with local rates. This is BTW the major reason why geographic numbers are popular for VoIP. On the other hand, this reason will go away soon. 3) Popular cities may run out of numbers, requiring numbering changes. Ok, this may be true in the NANP, (but they seem to have no real problems there, not even in Washington ;-) but definitely not in the short term in Germany and Austria with variable lenght numbering plans and a clever assignment procedure and routing procedure (e.g. not giving away full numbering blocks to VoIP providers, but single numbers). Also one may assume that fixed PSTN numbers are given up for mobile numbers, so they may be ported to VoIP 4) Emergency services will get problems if called by these numbers. This IMHO the real problem, but it needs to be solved in a differnt way: providing location information for VoIP calls in general. The simplest approach is to use the same mechanism (partially implemented already, partially planned) for mobile calls by providing actual location information during the emergency call. The proposed solution is as follows: As long as emergency services have no access to actual location databases and rely on static information for geographic numbers, calls originating with geographic numbers to emergency services SHALL do this ONLY from the location provided to the location database (e.g. phone book). If a call is originated from a VoIP phone, this implies the call is either originated from the given location (in which case the geographic number may be used) or if from somewhere else, a non-geographic number must be used to indicate to the emergency service that the address provided in the location database may be incorrect and the real location need to be found out if necessary. This implies that a non-geographic number range is readily available for this use. It is also advisable that calling this non-geographic number range from within a country should be comparable with local call rates, so the tariffing argument is not valid (this is also feasible from a PSTN point of view, assuming that calls to this number range is routed to local gateways anyway) Now this leaves three options for geographic numbers. A) Strict: you need a fixed access in the geographic area (e.g. a DSL or cable) to get a geographic number and you may receive and originate calls only from this location. B) Less strict: You need a fixed location in the geographic area to get a geographic number, but you may receive calls anywhere. You may originate calls using the geographic number only from this location, if you are not at this location, you may either not originate calls or use a different non-geographic number Note: Since A can be converted with simple Call Forwarding immediately to B, A is useless. C) Liberal: You may get a geographic number anywhere without a having an access there to receive calls, but you are not allowed to originate calls using this number. For originations you must use a non-geographic number. This seems to be what the consumer want. Additional notes to consider: The whole situation is completely out of control anyway and any regulation on this issue will only hinder companies (especially national ones) to pursue their business: What is in principle the difference to the above cases on VoIP if a have a PSTN line with a geographic number connected to a SPA-3000 with an FXO port an now I make a call out the PSTN in Vienna (especially to an emergency service) via t he Internet (e.g. from Boston). No regulator can prevent this an it has the same effect as above. So the only argument that remains is number exhaust and this argument is currently not existing. Just wait and see. regards Richard From Richard.Stastny at oefeg.at Tue Aug 24 17:33:04 2004 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Tue, 24 Aug 2004 17:33:04 +0200 Subject: [enum-wg] Contract for +43 ENUM Tier 1 Registry between RTR and enum.at Message-ID: <06CF906FE3998C4E944213062009F162443850@oefeg-s02.oefeg.loc> ENUM goes commercial in Austria RTR (the Austrian Regulator) and enum.at announced today officially in a common press conference the planned launch of a commercial ENUM service in Austria. The corresponding press releases can be found (in German) at enum.at Presseinformation (PDF) and RTR Presseinformation (PDF) During the press conference two presentations where given: Prasentation ENUM_was ist das.pdf (2986,77 kB) and Prasentation ENUM 24082004.pdf (553,99 kB) The major reason for the press conference was the presentation of the contract between RTR and enum.at regarding the operation of the ENUM Tier 1 Registry. The contract is also available at the RTR-webpage: ENUM_Vertrag.pdf (206,3 kB) Sorry, the contract is currently only available in German, and English version is under translation. The contract is about the ENUM Tier 1 Registry operation, but also gives obligations for the contracts between the ENUM Tier 1 Registry and the Registrars. It also defines the number ranges that will be available in ENUM and the validation and identification required for the different number ranges. The number ranges in ENUM will be: -geographic numbers -private networks (05) -mobile numbers (06xx) -non-geographic fixed numbers (0720) -ENUM-driven numbers (0780) -freephone numbers (0800) The validation and identification methods differ for the different number ranges, potential examples are given in the annex B of the contract. The contract also defines the data stored at the ENUM Tier 1 registry for each delegated number ("WHOIS capability"). In short: For control and escrow purposes the subscriber identity (name and address) is stored at the ENUM Tier 1 Registry (for numbers requiring identification), but not available for the general public. Publicly available is only the fact that the number is delegated and the registrar. This allows also for ENUM delegations without identification, given proper validation (e.g. for mobile prepaid numbers with SMS validation). > Richard Stastny OFEG Osterreichische Fernmeldetechnische Entwicklungs- und Forderungsgesellschaft mbH Buroadresse: Arsenal Objekt 24, 7. Stock, Bauteil Ost, A-1030 Wien Postadresse: Postfach 147, A-1103 Wien Telefon: +43 664 420 4100 Telefax: +43 1 79780 13 E-Mail: > Web: > Die in dieser Mitteilung und Anhangen enthaltenen Informationen sind ausschlie?lich fur den Adressaten bestimmt und konnen geheime, vertrauliche oder vor Weitergabe geschutzte Informationen enthalten. Falls es sich beim Leser dieses Absatzes nicht um den beabsichtigten Empfanger oder dessen Vertretung handelt, wird er hiermit in Kenntnis gesetzt, dass jegliche Weitergabe, Verteilung oder Vervielfaltigung dieser Mitteilung verboten ist. Sollte dieses Schreiben irrtumlich zugestellt worden sein, wird gebeten, den Absender zu benachrichtigen und die Mitteilung zu loschen, ohne Kopien einzubehalten. Danke. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Richard.Stastny at oefeg.at Fri Aug 27 12:19:57 2004 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Fri, 27 Aug 2004 12:19:57 +0200 Subject: [enum-wg] Recommended reading on Numbering Message-ID: <06CF906FE3998C4E944213062009F162443865@oefeg-s02.oefeg.loc> Hi folks, Richard Hill pointed recently to a very interesting paper on Numbering: http://www.satradehub.org/Data/Reports/Global%20numbering%20issues%20review.pdf The Title is "Numbering Trends: A Gobal Overview" by Claire Milne for the Regional Center for Southern Africa. The document analyses many of the current issues on numbering, what the issues and pit-falls are in setting-up or modifying a numbering plan and in doing so, it explains very well the terminology and also the background of existing numbering structures in different countries. Although VoIP and ENUM issues are excluded, it may serve as excellent introductory reading in numbering, especially for net-heads currently trying to set up their own numbering plans on the Internet ;-) regards Richard -----Original Message----- From: richard.hill at itu.int [mailto:richard.hill at itu.int] Sent: Thursday, August 26, 2004 5:24 PM To: tsg2q1 at ties.itu.int Subject: Possible information document The paper: http://www.satradehub.org/Data/Reports/Global%20numbering%20issues%20review. pdf by Claire Milne seems very informative to me. Unless there are objections, I propose to ask Claire if she would agree that I post it on the SG2 Information Documents site, at: http://www.itu.int/itudoc/itu-t/com2/infodocs/index.html Thanks and best, Richard ----------------------------------------- Richard Hill Counsellor, ITU-T SG2 International Telecommunication Union Place des Nations CH-1211 Geneva 20 Switzerland tel: +41 22 730 5887 FAX: +41 22 730 5853 Email: richard.hill at itu.int Study Group 2 email: tsbsg2 at itu.int From enumvoipsip.cs at schiefner.de Fri Aug 27 13:31:13 2004 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Fri, 27 Aug 2004 13:31:13 +0200 Subject: [enum-wg] ITU's interim ENUM procedures revised Message-ID: <412F1B81.8000300@schiefner.de> All, to be found at: http://www.itu.int/ITU-T/inr/enum/procedures.html The major addition are two paragraphs dealing with issues arising from countries with an integrated numbering plan, such as +1. Best, Carsten