- enum-wg - mailman.ripe.net

Survey on ENUM Projects
by Kim Davies 29 Sep '04

29 Sep '04

Dear all, As discussed recently on the list, the chairs have commenced preparing a status page to identify and document the various ENUM projects being conducted in different countries. We would like feedback on the formulation of the questions. At present they are based heavily on those developed by Joakim Strålmark of the Swedish PTS in a recent survey. If there is additional information that would be useful, or if there is a better formulation for the questions, please provide your input. Most important we would like contributions of information on the various trials being conducted, so we can start populating the table with data. The page is available for the moment at this address: http://www.centr.org/kim/enum/index.html best regards, kim -- Kim Davies, Council of European National Top Level Domain Registries Avenue Louise 327, B-1050 Brussels; Tel. +32 2 627 5550

3 2

ENM definition
by Marco bernardi 28 Sep '04

28 Sep '04

All, at last week's Ripe meeting there was an action point on me to provide ETSI definitions to be considered for inclusion in the ENUM questionnaire. Attached is the ETSI doc. Definitions are in section 3. regards marco

1 0

Fwd: RIPE 49 Presentation/Tech Prep for Chairs
by Patrik Fältström 22 Sep '04

22 Sep '04

People that will present things at the ENUM wg meeting, please use this upload facility to upload your presentations. They will appear on the PC in the room if you upload at least the day before the meeting, and at least in the documentation. Please also bring the presentation on USB-stick if you are nervous you uploaded the presentation "too late". paf Begin forwarded message: > From: Nick Hyrka <nick(a)ripe.net> > Date: September 10, 2004 15:36:57 BST > To: wg-chairs(a)ripe.net > Cc: meeting(a)ripe.net > Subject: RIPE 49 Presentation/Tech Prep for Chairs > > Dear Working Group Chairs and Co-Chairs, > > <Please forgive the length - this is a long mail.> > > Here is information on RIPE 49 presentation and technical issues. I've > tried to be as brief as possible and have included several issues in > one mail instead of sending many separate mails. > > Presentation issues > =============== > Chairs and other presenters at the meeting will have the options of: > - using their own laptops to present their material > - using the laptop provided by the RIPE NCC in each conference room > > The Working Group laptops are checked by our OPS staff and offer the > presenter a working environment. This should reduce or eliminate > disruptions to the meeting caused by swapping laptops. > > Another advantage is that the presentations will be available on the > www.ripe.net website.This offers the possibility to look at the > webpages while listening to the webcast. > > Please also know that the KVM switch set-up has been improved. > > There are two ways to upload your presentation: > > - using the new presentation uploading facility > - using the ftp uploading area as before > > Presentation Uploading Facility > ======================= > For RIPE 49, our updated presentation uploading facility will be > available. The upload address is > https://www.ripe.net/cgi-bin/ripemtg/web_upload.pl > > The www web_upload link should be treated as confidential and should > only be used by WG Chairs and presenters. > > The upload form is available from 1 September. > > The upload form asks several questions, and all must be answered. > (i.e., speaker name, e-mail address, subject, description, Working > Group and the file). > > Upon successful uploading, the presenter will receive a notification > by e-mail. Therefore, make > sure your e-mail address is correct! > > The presenter will also see a webpage that the presentation has been > successfully uploaded. Our Webmaster will receive a notification as > well. > > The upload webpage also shows the location of the presentation. > Therefore, it is possible to immediately check the 'location/page' on > the website for your uploaded presentation. > > Presenters can overwrite their presentations by uploading a new one. > > Uploaded PowerPoint presentations will switch to full screen after > opening. > > Within the upload facility we have included some "hints and tips" for > other file formats. > > There will be a syncing mechanism in place in the week of the RIPE 49 > meeting. www.rosie.ripe.net (for attendees only) will have the > presentations online. > > Any NCC technical support person can assist you with uploading your > presentations with a memory stick in case you have problems. > > Uploading Presentations via ftp > ====================== > We will also offer the possibility to upload a presentation by ftp. > > To upload presentations via ftp, just follow these instructions: > > 1.) ftp rosie.ripe.net > This is only possible from within the RIPE Meeting address space > (193.0.8/23) from 19 September. > 2.) Login as ftp > Please provide a valid e-mail address as your password. > 3.) cd wg-name ('ls' to see a list of directories) > All Working Groups, EOF and the Plenary have a separate sub-directory > where presentations may be downloaded. Only these sub-directories are > writable by ftp. > Note that it is not possible to delete or rename presentations once > they are uploaded. Uploaded presentations will be immediately > available on the Working Group laptops for the presenters to access. > 4.) Naming your presentation > Please name your presentation something more descriptive (not, for > example, 'ripe49.ppt' ). Consider using something like > 'attendeename-subject.ppt' (eg. john_doe- whoisdb_tricks.ppt). > > NOTE: If these presentation uploading options fail you, the Operations > Team can provide you with a memory stick along with general support. > > Presentations - style guideline > ====================== > As all sessions will be webcast, here are some suggested guidelines on > presentation preparation to help ensure easy-to-see/understand > information on slides: > > - limit the number of slides to avoid information overload > - use less text and a larger font size so that attendees in the rear > of the room and those viewing webcasts can see the text > - use a standard font, such as Helvetica or Arial, as they are highly > readable > > IRC/Jabber > ======== > IRC (Internet Relay Chat) and Jabber will be provided for use at RIPE > 49. > > As this will be offered on a trial basis, remote attendees who wish to > participate in the meeting will be encouraged to find a proxy who will > present their questions at the meeting. > > Staff from the RIPE NCC will provide monitoring of discussions and > will alert the WG Chair if any questions or statements need to be > recognised. The NCC staff will not provide written responses or > summaries of the discussions. > > Feedback submitted through IRC/Jabber will be archived and made > available on the RIPE NCC website. > > If you do not have an IRC or Jabber client already installed in your > computer, we recommend that you download and register a client when > you arrive at the meeting and before your first session. > > Links to clients and more information on the details of the RIPE 49 > trial feedback mechanisms can be found at: > http://www.ripe.net/ripe/meetings/ripe-49/feedback.html > > If you have any questions about IRC/Jabber or any other technical > issue, the Operations Team, headed by Cagri Coltekin, will be located > in the Bernini Suite. Cagri and his crew will be happy to help you. > > Webcast & Audiocast > ================ > All sessions will be available via the RIPE webcast and archived. > Sessions in the Medici Room will have both video and audio, whilst all > other sessions will be audio only. > > We encourage you to ask session attendees to always approach the > microphones when they have a question or comment. Please tell them to > state their names and speak clearly. > > ROSIE > ===== > Once again, the RIPE On Site Information Exchange (ROSIE) will be > available providing important meeting information: > http://rosie.ripe.net > > That's all for now. Please do not hesitate to contact Camilla or me if > you have any questions. > > Best regards, > Nick > >

1 0

IDA Seeks Industry Feedback on Telecoms Policy Regarding Internet Protocol (IP) Telephony and Electronic Numbering
by James Seng 21 Sep '04

21 Sep '04

http://www.ida.gov.sg//idaweb/media/infopage.jsp?infopagecategory=&infopage… Singapore, 21 September 2004| For Immediate Release As part of its continuing efforts to engage the public in policy development to benefit the infocomm industry, the Infocomm Development Authority of Singapore (IDA) seeks views on the policy framework to facilitate the introduction of Internet Protocol (IP) Telephony and Electronic Numbering (ENUM) in Singapore. The Internet and other IP-based networks are increasingly used by consumers for voice communications (e.g. international voice calls) in combination with, or as an alternative to fixed-line telephony. IP Telephony referred to in IDA's proposed policy framework is a form of Voice over Internet Protocol (VoIP)1 service that requires traditional local telephone numbers. It allows consumers to make and receive voice, data and video calls using the same telephone number, from any domestic or overseas location with available Internet access. IDA is also seeking public and industry views on ENUM. Through ENUM, consumers use a single electronic number in place of multiple contacts, such as telephone and fax numbers, URLs, and email addresses. ENUM is a protocol that translates a normal telephone number into a format that stores and retrieves Internet addressing information, which in turn, can be used to route communications over the Internet. With increased interest in the provision of IP Telephony services, IDA is seeking views on a suitable policy approach towards IP Telephony and ENUM. Such consultation is in line with IDA's efforts to help ensure that telecoms policies remain relevant, while continuing to sustain and encourage a competitive market environment to the benefit of businesses and consumers. All views and comments should be submitted in writing to IDA by 12 noon (Singapore time) on Friday, 22 October 2004. IDA will consider all submitted inputs before issuing its final policy decision. The public consultation paper can be downloaded from http://www.ida.gov.sg/ , under the sections "Policy & Regulation", "Consultation Papers".

1 0

UK Consultation
by Patrik Fältström 21 Sep '04

21 Sep '04

We will also get a presentation from DTI in the UK regarding the consultation made. Patrik

1 0

Scribe?
by Patrik Fältström 21 Sep '04

21 Sep '04

Do we have a volunteer to be scribe at the meeting Thursday afternoon? paf

1 0

IDA Seeks Industry Feedback on Telecoms Policy Regarding Internet Protocol (IP) Telephony and Electronic Numbering
by James Seng 21 Sep '04

21 Sep '04

http://www.ida.gov.sg//idaweb/media/infopage.jsp?infopagecategory=&infopage… Singapore, 21 September 2004| For Immediate Release As part of its continuing efforts to engage the public in policy development to benefit the infocomm industry, the Infocomm Development Authority of Singapore (IDA) seeks views on the policy framework to facilitate the introduction of Internet Protocol (IP) Telephony and Electronic Numbering (ENUM) in Singapore. The Internet and other IP-based networks are increasingly used by consumers for voice communications (e.g. international voice calls) in combination with, or as an alternative to fixed-line telephony. IP Telephony referred to in IDA's proposed policy framework is a form of Voice over Internet Protocol (VoIP)1 service that requires traditional local telephone numbers. It allows consumers to make and receive voice, data and video calls using the same telephone number, from any domestic or overseas location with available Internet access. IDA is also seeking public and industry views on ENUM. Through ENUM, consumers use a single electronic number in place of multiple contacts, such as telephone and fax numbers, URLs, and email addresses. ENUM is a protocol that translates a normal telephone number into a format that stores and retrieves Internet addressing information, which in turn, can be used to route communications over the Internet. With increased interest in the provision of IP Telephony services, IDA is seeking views on a suitable policy approach towards IP Telephony and ENUM. Such consultation is in line with IDA's efforts to help ensure that telecoms policies remain relevant, while continuing to sustain and encourage a competitive market environment to the benefit of businesses and consumers. All views and comments should be submitted in writing to IDA by 12 noon (Singapore time) on Friday, 22 October 2004. IDA will consider all submitted inputs before issuing its final policy decision. The public consultation paper can be downloaded from http://www.ida.gov.sg/ , under the sections "Policy & Regulation", "Consultation Papers".

1 0

+46 presentation on Thursday
by Patrik Fältström 21 Sep '04

21 Sep '04

I just got info from Jakob Schlyter that he is happy to talk about the conclusions in Sweden... paf

1 0

2nd Plugtests ENUM Workshop 4.-8.October CANCELLED
by Stastny Richard 14 Sep '04

14 Sep '04

Dear all, the 2nd Plugtests ENUM Workshop scheduled from 4.-8.October at ETSI Sophia Antipolis has been cannecelled due lack of participants. The preparation for the 3rd Workshop and NGN VoIP ENUM Plugtest in 29.Nov-3.Dec in ETSI Sophia Antipolis will take place during the normal ETSI TISPAN#4 WG4 Meetings 13.9-17.9 2004 and TISPAN#4bis 2.-5-Nov 2004. best regards Richard Stastny

1 0

Re: [enum-wg] Survey on ENUM Projects - Austria +43
by Stastny Richard 10 Sep '04

10 Sep '04

Dear Kim and all, First a feedback on the questions: The following 2 questions should be added: 5a. Types of numbers used in the trial? 6a. Types of numbers for production? Response to the question for Austria +43 1. What is the country and E.164 code? CC +43 The Austrian Numbering and Dialing Plan is open and has variable number lenght N(S)N (both area codes and subscriber numbers). See http://www.rtr.at/web.nsf/englisch/Telekommunikation_Nummerierung_Nationale… . It is defined in the RTR's 6th Ordinance of May 12, 2004 which defines regulations for communication parameters, fees and value-added services (KEM-V). The KEM-V (in German can be downloaded from http://www.rtr.at/web.nsf/englisch/Telekommunikation_Telekommunikationsrech… The KEM-V defines regarding E.164 numbers the following types of numbersin the number ranges: - geographical numbers (+43 1 to +43 7xxx) - numbers for private networks (+43 5xxxx) - mobile numbers (+43 6xx) - location-independant fixed network numbers (+43 720) - numbers for converged services (ENUM enabled) (+43 780) - free-phone numbers (+43 800) - premium rate and value-added services (+43 8xx and 9xx) 2. Who is the delegate for the E.164 code? With the consent of the Austrian Federal Minister for Transport, Innovation and Technology granted on June 7, 2002, RTR is the domain name holder for the national ENUM domain 3.4.e164.arpa in Austria. RTR: Rundfunk und Telekom Regulierungs-GmbH (Austrian Regulatory Authority for Broadcasting and Telecommunications) Mariahilfer Strasse 77-79 A-1060 Vienna, Austria Tel.: +43 (0) 1 58058 - 0, Fax: +43 (0) 1 58058 - 9191 E-Mail: mailto:rtr@rtr.at Web: http://www.rtr.at 3. The status of deployment (notdelegated>applied>delegated/objected>trial>hiatus>production) Current Status: Trial since september 2002 Production planned November 2004 4.ENUM Project contact details (telephone, email, web) Austrian ENUM Trial Platform http://enum.nic.at Chair: Richard Stastny, +43 664 420 4100, richard.stastny(a)oefeg.at Vice: Michael Haberler, +43 664 421 3465, mah(a)nic.at Hosted by: OeFEG Arsenal Objekt 24 PO Box 147 A-1103 Vienna, Austria 5. Is a trial being, or going to be, conducted? yes, trial conducted since September 2002 5a. Types of numbers used in the trial? -geographic numbers -numbers for private networks -mobile numbers 6. Is there work or plans toward full permanent deployment? Yes, production planned November 2004 6a. Types of numbers for production? - geographical numbers - numbers for private networks (+43 5xxxx) - mobile numbers (+43 6xx) - location-independant fixed network numbers (+43 720) - numbers for converged services (ENUM enabled) (+43 780) - free-phone numbers (+43 800) for more details see contract between RTR and enum.at (see below) 7. Who is leading the ENUM project? (government, industry working group, etc.) Austrian ENUM (Trial) Platform Industry working group with goverment (RTR) participation 8. Who operates the ccTLD for that country at present? nic.at nic.at Internet Verwaltungs- und Betriebsgesellschaft m. b. H. Jakob-Haringer-Straße 8 5020 Salzburg Austria Telefon +43 (662) 4669-0 Fax +43 (662) 4669-29 http://www.nic.at 9. What type of organisation runs the ccTLD? (state, private, academic, etc.) private, but owned by IPA (Internet Privatstiftung Austria/Internet Foundation Austria). See http://www.nic.at/en/company/internetaustria/ia_internetaustria.asp 10.What is the ccTLD legal regulation, if any? See charter of the Austrian Domain Registration http://www.nic.at/en/company/internetaustria/ip_ipaprinzipien.asp 11.Who is the current Tier 1 registry? nic.at 12.Who is, or will be, the permanent Tier 1 registry? enum.at enum.at Dienstleistungs GmbH für konvergente Kommunikationsdienste Karlsplatz 1/9 A-1010 Vienna, Austria email: office(a)enum.at Telefon: +43 (1) 50564 16 - 0 Fax: +43 (1) 50564 16 - 19 web: http://www.enum.at enum.at is also owned by IPA and a sister-company of nic.at 13.How will the Tier 1 registry selection be made? (i.e. decision, license, concession, agreement, public procurement, etc.) decision made Ausgust 2004 by contract between RTR and enum.at until End of 2007 The contract in English can be downloaded from: http://www.rtr.at/web.nsf/englisch/Telekommunikation_Nummerierung_ENUM 14.How will the method of cost recovery for the Tier 1 registry's operations? Monthly fees for Registrars (approx. 0.25 - 0.5 Euro/Month/Domain) 15.Will there be more than one Tier 1 provider for the country? No 16.Will there be ENUM registrars? Yes 17.What will be the ENUM validation technique? Various, also depending on type of number Basic requirements for Registrars and Validation Entities given in the contract between RTR and enum.at 18.Is there/will there be a special number block for ENUM and/or IP Telephony? Yes, - numbers for converged services (ENUM enabled) (+43 780) 19.Is there special treatment for unlisted numbers? No 20.Are there any plans for infrastructure ENUM? 21.What is your ENUM WHOIS address? For the trial: via http://enum.nic.at <http://enum.nic.at> For production: not yet defined The public WHOIS will only contain the domain, if delegated and the Registrar 22.Please provide the history of ENUM trials, projects etc., if any. 2001-08 First consulation by Austrian regulator (RTR) 2002-02 ENUM Workshop RTR, group of interested partners formed 2002-05 Interim procedures from ITU-T SG2 and TSB Delegation request by RTR to RIPE and ITU-TSB 2002-06 Tier 1 Registry in operation by NIC.AT (the Austrian ccTLD) Delegations for 3.4.e164.arpa from RIPE to nic.at Start of development and deployment 2002-07 First draft of policy framework for MoU of trial by RTR 2002-09 Austrian ENUM Trial Platform established Founding Members: RTR, nic.at, Telekom Austria, OeFEG, Siemens, Kapsch carrierCom, Infonova (BearingPoint) ENUM Tier 2 Nameserver (Telekom Austria) in operation First clients available (ENUM queries on public Internet) 2002-10 Web-Portal for registration and modification in operation SIP and H.323 VoIP applications available First Live Demo in Atlanta, GA (VISIONng/VON/TIPHON) Set-up of Call Center and Registrar (Telekom Austria) 2002-11 ENUM Tier 1 Registry processes fully automated (Nic.at) Test of provisioning processes with selected subscribers Policy Framework and MoU ready -> trial started officially with geographic and mobile numbers 2002-12 Ready to invite real ENUM subscribers and users Live demo of all functions at the ITU-T SG-2 meeting in Geneva 2003-01 ETSI TS 102 172 finalized 2003-02 Conversion to ETSI TS 102 172 compliance 2003-10 First part of trial completed, second phase started (business customers) 2003-11 Decision by RTR to allow numbers for private networks in addition 2003-12 Large Scale ENUM and VoIP Pilot started at the Uni Vienna (AT43) 2004-05 Decision by Austrian ENUM Trial Platform to prepare for production 2004-08 Contract between RTR and enum.at on Tier 1 Registry operation 23.What are your future plans? (and dates if available) Launch Production in November 2004 24.What is your date estimate on a production ENUM registry launch? Nov 2004 Launch of production Jan 2005 Start of Billing for Registrars best regards Richard Stastny Chiar Austrian ENUM Trial Platform

1 0

Re: [enum-wg] Survey on ENUM Projects
by Stastny Richard 08 Sep '04

08 Sep '04

Hi Kim, just to get the basic information on Austria and VISIONng correct:: Status: trial (since September 2002) Tier 1 Registry:: nic,at Webpage: http://enum.nic.at For Austria in addition: Production: planned November 2004 Tier 1 registry: enum.at Webpage: www.enum.at more detailed answers to the questions will follow regards Richard Stastny Chair Austrian ENUM Platform -----Ursprüngliche Nachricht----- Von: Kim Davies [mailto:kim@centr.org] Gesendet: Mi 08.09.2004 17:47 An: enum-wg(a)ripe.net Cc: Betreff: [enum-wg] Survey on ENUM Projects Dear all, As discussed recently on the list, the chairs have commenced preparing a status page to identify and document the various ENUM projects being conducted in different countries. We would like feedback on the formulation of the questions. At present they are based heavily on those developed by Joakim Strålmark of the Swedish PTS in a recent survey. If there is additional information that would be useful, or if there is a better formulation for the questions, please provide your input. Most important we would like contributions of information on the various trials being conducted, so we can start populating the table with data. The page is available for the moment at this address: http://www.centr.org/kim/enum/index.html best regards, kim -- Kim Davies, Council of European National Top Level Domain Registries Avenue Louise 327, B-1050 Brussels; Tel. +32 2 627 5550

1 0

ITU's interim ENUM procedures revised
by Carsten Schiefner 27 Aug '04

27 Aug '04

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

1 0

Recommended reading on Numbering
by Stastny Richard 27 Aug '04

27 Aug '04

Hi folks, Richard Hill pointed recently to a very interesting paper on Numbering: http://www.satradehub.org/Data/Reports/Global%20numbering%20issues%20review… 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(a)itu.int [mailto:richard.hill@itu.int] Sent: Thursday, August 26, 2004 5:24 PM To: tsg2q1(a)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(a)itu.int Study Group 2 email: tsbsg2(a)itu.int

1 0

Contract for +43 ENUM Tier 1 Registry between RTR and enum.at
by Stastny Richard 24 Aug '04

24 Aug '04

ENUM goes commercial in Austria RTR <http://www.rtr.at> (the Austrian Regulator) and enum.at <http://www.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) <http://www.enum.at/PK_Info_ENUM.pdf> and RTR Presseinformation (PDF) <http://www.enum.at/RTR_Meldung.pdf> During the press conference two presentations where given: Prasentation ENUM_was ist das.pdf (2986,77 kB) <http://www.rtr.at/web.nsf/lookuid/AF61B055A7CE3EB8C1256EFA00294001/$fil e/Prasentation%20ENUM_was%20ist%20das.pdf> and Prasentation ENUM 24082004.pdf (553,99 kB) <http://www.rtr.at/web.nsf/lookuid/AF61B055A7CE3EB8C1256EFA00294001/$fil e/Prasentation%20ENUM%2024082004.pdf> 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) <http://www.rtr.at/web.nsf/lookuid/AB9BE747D5DAAA41C1256EFA0031842C/$fil e/ENUM_Vertrag.pdf> 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: <mailto:richard.stastny@oefeg.at <mailto:richard.stastny@oefeg.at> > Web: <http://www.oefeg.at <http://www.oefeg.at/> > 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.

1 0

Re: [enum-wg] .de regulator starts proceeding against voip providers using +49 numbers for voip
by Stastny Richard 21 Aug '04

21 Aug '04

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

1 0

.de regulator starts proceeding against voip providers using +49 numbers for voip
by Chris Heinze 21 Aug '04

21 Aug '04

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

3 4

repost: Proposal for non-geographic ENUM E.164 UPTS for the general public
by Chris Heinze 19 Aug '04

19 Aug '04

hi! the company i'm with is providing services in the voip-area, and we had and still have our problems with the situation with telephone-numbers for voip-services in general. we were observing that other companies have the same and similar problems, and that several - mostly quite ugly - workarounds are being started, but that's all not very promising. also recent trials and decisions in our region didn't make us very confident that there's a working solution to this problem anywhere in sight. so we thought it might be a good time to start a discussion about possible solutions to the telephone-number problems, and we consider the just-in-time creation of the ripe enum-wg a good omen. ;) we put together a kind of proposal for a possible solution, just to contribute to the discussion and have something to talk about. we're very curious whether there is general support for a request of non-geographical E.164 UPTS-space for enduser-assignments handled by public registries, and in case there is, what is your idea about the following proposal, what should be done different? we're hoping some proposal for action towards some solution that is capable of finding consensus in the WG and the respective other involved institutions can be produced. so let's become formal and to the point: ----- snip ----- Proposal for a public registry system for non-geographic E.164 UPTS assignments and the respective ENUM space ============================================================================================================= Version ------- This document is version 0.1 of the ENUM E.164 UPTS proposal, dated 16 June 2004. Status ------ This document is still in draft form and is open to discussion from all parties. Scope ----- The intended audience for this document is the RIPE ENUM-WG. Once consensus has been reached the intended audience should be expanded to RIPE Services-WG, RIPE DNS-WG, RIPE DB-WG, RIPE Policy-WG, the respective groups of the other RIRs, and/or any other involved parties. Comments to the authors are encouraged. 1. Introduction --------------- In today's internet there is already a large variety of digits-only VoIP devices on the market, also working VoIP-PSTN-gates are available. In the same time there is no registry able to provide for assignments of appropriate telephone numbers according to ITU-T E.164 (i.e. reachable in the international telephone system) and the respective ENUM delegation to the general public. Currently workarounds are being developed (reassignments of geographic-CC numbers, alternative ENUM-trees, non-regional national CC numbers, etc.) resulting in isolated numberspaces, user confusion, and possible future problems resulting from lack of coordination. Because of this current situation there is an immediate need for non-geographic ENUM enabled E.164 UPTS space available for assignments to the general public, and creation of a structure to handle registry tasks, both administrative and operational. 2. Goals -------- The requirements for the registry: - provide undiscriminatory service to the general public (which implies independence towards commercial markets and nations) - provide global service (which implies independence from nations) - provide stable registry and ENUM service - development of policies (which implies the need for some sort of legitimation from the community) The requirements for the number space: - part of the international telephone number space (implies ITU-T E.164) - non-geographic - enduser-specific (UPTS) - fully portable 3. Registry System ------------------ The NRO as the 'community of RIRs', meeting all requirements and already providing a working structure and experience for such a registry, acts as the formal registry (Tier 1) for the assigned ENUM E.164 UPTS space. 3.1 Registry: allocations/assignments ------------------------------------- The RIPE (or a different RIR acting as central coordination point) allocates parts of the assigned ENUM E.164 UPTS space to the RIRs (including itself). The RIRs allocate parts of their respective allocations to their LIRs. LIRs assign numbers from their blocks to endusers. Assignments are enduser-specific (like IPv4 PI), i.e. the allocation to LIRs is just for new assignments, when an enduser changes serviceproviders the authority for the assignment moves with the enduser. 3.2 Registry: database ---------------------- As database for allocations and assignments, whois is used. The whole block assigned by ITU-T is entered as one domain object, with mnt and mnt-lower set to an appropriate maintainer from RIPE (or a different RIR acting as central coordination point). When a block is allocated to a RIR, RIPE creates the respective domain object, entering an appropriate maintainer from the respective RIR as mnt and mnt-lower. When a block is allocated to a LIR, the respective RIR creates the respective domain object, entering an appropriate maintainer from the respective LIR as mnt and mnt-lower. When a number is assigned to an enduser, a maintainer according to the enduser's wishes might be entered. When the enduser changes service providers, a different maintainer can be entered. 3.3 Registry: ENUM ------------------ ENUM delegations are done upon allocation or assignment, i.e.: ITU-T (resp. RIPE acting as Tier 0 for ITU-T) delegates ENUM for the assigned block to RIPE (or a different RIR acting as central coordination point). When a block is allocated to a RIR, the respective ENUM delegations to the RIR are done. The RIR creates its delegations from its database by querying for all most-specific objects (this is important to achieve full portability). 3.4 Registry: ENUM delegation from database ------------------------------------------- RIPE (or a different RIR acting as central coordination point) has to make sure that upon allocation of a block to a RIR, the necessary ENUM delegations are made. As the kind of mechanism used to achieve this doesn't influence procedures in the RIRs, it's only the central coordination point's matter how this is done. But this could be done by the nserver attributes of the domain objects entered upon allocation, and the nameserver configuration could easily be created automatically in such a way. RIRs have to generate delegations in their nameservers from the most specific domain objects. This way the necessary nameserver configuration can be created automatically, isn't dependent on a fixed allocation/assignment length, and provides for full portability. 3.5 Registry: policies ---------------------- A policy for allocation of blocks to the RIRs should be developed in the NRO context. A policy for allocation of blocks to the LIRs and a policy for assignment to endusers by LIRs should be developed by the respective RIR, but common policies (via NRO) might be desirable. All allocations or assignments should be done on request only, a initial automatic allocation of blocks to RIR-members should be deprecated for number space conservation reasons. The assignment policy for LIRs should demonstrate what is considered good practise. Possible norms could regard to the size of blocks assigned to entities (e.g. a fixed assignment length), the number of assignments to entities, and whether an assignment has to be deleted when the enduser is giving it up (i.e. does it have to be available for reassignment by the LIR who initially received the respective block for new assignments or is it ok for the last maintainer/service provider to reuse it?). LIRs receive allocations of blocks from RIRs as a means of moving the work necessary for assignments to the member-level where the request was delivered, and where service is done directly to the enduser. To install some kind of quality assurance, it's proposed to introduce a slow-start mechanism just like with IPv4 PA assignments: initial assignments have to be approved by a RIR hostmaster, until it is decided by the RIR to give the LIR an assignment window, which will be increased when the LIR demonstrated sufficient experience. 4. E.164 UPTS space ------------------- The RIRs request from the ITU-T TSB assignment of non-geographic E.164 UPTS space (i.e. a block under CC878) to the NRO and the respective ENUM delegation to RIPE. It might be worth considering explicitly requesting a short (i.e. 1 digit) prefix to have a number space as large as possible to attenuate ENUM block-delegation issues. I guess the community might like the idea of a sub-block identifier '7' (i.e. +8787 with an 11 digits space) 5. Actions ---------- 1.) discussion in RIPE ENUM-WG on UPTS-space for enduser-assignments handled by RIRs in case of general support of ENUM-WG: 2.) discussion in RIPE ENUM-WG, Services-WG, DNS-WG, and DB-WG on request for registry service (tier 1) operations run by RIPE in case of general support of ENUM-WG and Services-WG: 3.) discussion in RIPE Address Policy-WG on ENUM878x allocation/assignment policies in case of a consensus on (preliminary) policies: 4.) discussion in NRO context (actions 2, 3, and 4 might be intermixed) in case of a consensus on (preliminary) policies: 5.) request to ITU-T TSB for delegation of a non-geographic UPTS block under E.164 CC878 to the RIRs (formally NRO, or RIPE acting in consensus with RIR-community) ----- snap ----- kind regards, Chris Heinze

6 22

Re: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public
by Richard Shockey 11 Aug '04

11 Aug '04

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@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 <mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz> <http://www.neustar.biz> ; <http://www.enum.org> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

2 1

Re: [enum-wg] New Subject: What ENUM wg should do...
by Jim Reid 11 Aug '04

11 Aug '04

>>>>> "paf" == =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= <ISO-8859-1> 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!

4 4

Re: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public
by Jim Reid 11 Aug '04

11 Aug '04

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.

5 4

Re: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public
by Jim Reid 11 Aug '04

11 Aug '04

>>>>> "Chris" == Chris Heinze <x(a)ccn.net> 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.

3 2

UK ENUM consultation
by Carsten Schiefner 10 Aug '04

10 Aug '04

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(a)nominet.org.uk Date: Tue, August 10, 2004 4:01 am To: nom-announce(a)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

1 0

Re: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public
by Stastny Richard 10 Aug '04

10 Aug '04

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@cisco.com] Gesendet: Mo 09.08.2004 20:32 An: Chris Heinze Cc: enum-wg(a)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 >

3 2

RE: [enum-wg] repost: Proposal for non-geographic ENUM E.164 UPTS for the general public
by McCandless, Kevin 09 Aug '04

09 Aug '04

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

1 0

Closing <enum-trials@ripe.net>
by RIPE NCC WebMaster 05 Aug '04

05 Aug '04

Dear Colleagues, Following the official formation of the ENUM Working Group at RIPE 48, Amsterdam we have moved all subscribers of <enum-trials(a)ripe.net> to the newly created working group mailing list <enum-wg(a)ripe.net>. The <enum-trials(a)ripe.net> mailing list will shortly be closed. If you wish to unsubscribe from <enum-wg(a)ripe.net> 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 <webmaster(a)ripe.net>. Regards, RIPE NCC WEBMASTER ==================

1 0

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

31 Jul '04

hi everyone/anyone... ;) accounting the lack of criticism i suppose the proposal is generally considered acceptable. well then i'd suggest to vote on this proposal on ripe49. kind regards, Chris Heinze

4 3

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Niall O'Reilly 15 Jul '04

15 Jul '04

On 15 Jul 2004, at 14:40, Jim Reid wrote: > So you can try different > delegation approaches and see what works and what doesn't. And aside > from the DNS mechanics, you can consider things like the impact of a > particular approach on interfaces, roles & responsibilities as well as > stuff like competition policy and the public interest. IMO it's far > more important to learn about these things than focus on which name > server(s) some zone sits on. No dispute there! Best regards, Niall O'Reilly UCD Computing Services

1 0

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Niall O'Reilly 15 Jul '04

15 Jul '04

On 15 Jul 2004, at 11:07, Jim Reid wrote: > And it will > make DNSSEC deployment (hah!) much harder because the parent can't > secure any delegations with DS records because there are no proper > delegations. So, we'd better make sure our trial doesn't take longer than six months ? 8-) Seriously, though, this is something I need to avoid losing sight of. Thanks. > DNAME is even worse because there are plenty of name > servers and resolvers out there that don't understand this RR. This also. thanks again. > It's > not impossible that some applications will get upset if they get > CNAME-like referrals to their lookups when they only expected to get > NAPTR RRs or conventional referrals. For instance think of someone who > writes a minimal ENUM-aware resolver as a Java applet for their mobile > phone. Nobody with significant market share would be involved in inflicting such a broken application on the unsuspecting customers, would they ? 8-) Best regards, Niall O'Reilly UCD Computing Services

1 0

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Niall O'Reilly 15 Jul '04

15 Jul '04

On 15 Jul 2004, at 11:07, Jim Reid wrote: > Another problem -- which won't apply to someone clueful like you -- is > that the introduction of CNAMEs increases the likelihood of looping or > very long CNAME chains. Or dangling CNAMEs that point at nothing. Even > without these administrative errors, the introduction of CNAMEs will > complicate ENUM lookups and could mean they take too long. This would > be somewhat annoying when someone picks up their ENUM-aware phone, > dials a number and then waits for an eternity while the resolver > chases down umpteen CNAME chains before making a phone ring. IMO it's > best not to give people access to that much rope to hang themselves. OTOH, there's a balance to be struck between allowing people to be responsible for their own mistakes and engaging in the diminishing-returns game of protecting them from everything. If registrars or T2 registries can't do their job, how long will they stay in business ? Best regards, Niall O'Reilly UCD Computing Services

1 0

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Niall O'Reilly 15 Jul '04

15 Jul '04

On 15 Jul 2004, at 11:07, Jim Reid wrote: > You lose the granularity of control and the flexibility to let > customers manage their delegations. I'm presuming you plan to have all > your numbers CNAME'd into a single zone file rather than discrete zone > files for each zone. I see it quite the other way around: you _gain_ flexibility. The customer has a single point of administration for announcing the delegation and changes thereto. Once the CNAME has aged out from resolver caches, there is no trace left of obsolete data in the 'golden tree'. If the T2 provider which the customer has just deserted delays (or neglects) removing the relevant RRsets, so what ? With NS, on the other hand, you have to make sure that all the obsolete data on still authoritative servers is eliminated. > This might also get you into trouble with the > competition authorities because the people using these CNAME'd numbers > are locked in to your way of doing things. Are you saying that the opportunity for restrictive practices is significantly different according to which method you choose for implementing delegation ? I really don't see this. > For something like a DDI > block for an organisation, this shouldn't be an issue. But if it was > for all numbers in the Dublin area code (say), there would be a > problem. How is this different between the NS and CNAME implementations ? > Registrants won't have the freedom to choose and switch DNS > providers. Or decouple DNS hosting from the ISP/registrar they use to > get their ENUM delegation. See above. Best regards, Niall O'Reilly UCD Computing Services

1 0

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Niall O'Reilly 15 Jul '04

15 Jul '04

Jim, Thanks for the comprehensive comments. I'ld like to reply to one chunk at a time. [dns-wg-ers, sorry for the cross-posting; I'ld use enum-wg if it were populated.] On 15 Jul 2004, at 11:07, Jim Reid wrote: > So what? Is disk space and RAM expensive? No. T1 zone-file size is indeed no big deal, mentioned for completeness only. > The T1 registry is going to > be storing so much data about its registrations -- tech & admin > contact details, billing info, authentication/validation tokens, whois > tags, registrar data, etc, etc -- that shaving off a couple of > resource records would be lost in the noise. Only if your (unstated) assumptions about the role of the T1 Registry match the particular instance. My concept of the T1 Registry is much lighter, with delegation only at T1, payload (NAPTR of course, possibly others) at T2, and validation with the registRARs. This distributes customer-related overhead to the front-office, where it can be related directly to each registrar's business. > For the T1, adding CNAMEs > instead of conventional delegations might well be an unwanted > complication: ie it requires changes and on-going support to the > registry database and back-end scripts and tools. IIUC some registry > systems only handle the RRs needed for conventional delegation: NS > records and related glue. IMHO such registry systems are not suited to the ENUM business, and a T1 which takes this approach is unlikely to be winning many tenders for national infrastructure. Of course, that depends on the clue-level available to the local awarding agency. I'm happy to say that, here in +353-land, our trial T1 is taking a more helpful approach. Best regards, Niall O'Reilly UCD Computing Services

1 0

Tier-2 provisioning: NS vs CNAME/DNAME
by Niall O'Reilly 07 Jul '04

07 Jul '04

Hello ENUMmers, I'm about to become responsible for a Tier-2 ENUM registry, part of the Irish ENUM Trial. I expect to use BIND as the name server platform for this purpose. I have supposed (perhaps naïvely) that the conventional delegation mechanism, using NS records in the parent zone, would be appropriate. This involves creating a new zone as each new telephone number is registered, and configuring the zone specifically on each of Tier-2 name servers. I'm not sure I really want to buy in to this level of per-number provisioning activity, and see apparently significant advantages in using the technique of RFC2317 (Classless IN-ADDR.ARPA delegation) to make life simpler. The advantages I see are the following. The Tier-1 zone file becomes smaller, with just one CNAME (or DNAME) record per delegation, rather than two or more NS records. At Tier 2, the named configuration file needs only per-server, rather than per-number- per-server provisioning activity, and propagation of newly-registered numbers is driven by NOTIFY rather than by reloading the updated configuration file on each server. This looks like the way to go, but perhaps I'm missing something ? Best regards, Niall O'Reilly UCD Computing Services

1 0

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

16 Jun '04

hi! the company i'm with is providing services in the voip-area, and we had and still have our problems with the situation with telephone-numbers for voip-services in general. we were observing that other companies have the same and similar problems, and that several - mostly quite ugly - workarounds are being started, but that's all not very promising. also recent trials and decisions in our region didn't make us very confident that there's a working solution to this problem anywhere in sight. so we thought it might be a good time to start a discussion about possible solutions to the telephone-number problems, and we consider the just-in-time creation of the ripe enum-wg a good omen. ;) we put together a kind of proposal for a possible solution, just to contribute to the discussion and have something to talk about. we're very curious whether there is general support for a request of non-geographical E.164 UPTS-space for enduser-assignments handled by public registries, and in case there is, what is your idea about the following proposal, what should be done different? we're hoping some proposal for action towards some solution that is capable of finding consensus in the WG and the respective other involved institutions can be produced. so let's become formal and to the point: ----- snip ----- Proposal for a public registry system for non-geographic E.164 UPTS assignments and the respective ENUM space ============================================================================================================= Version ------- This document is version 0.1 of the ENUM E.164 UPTS proposal, dated 16 June 2004. Status ------ This document is still in draft form and is open to discussion from all parties. Scope ----- The intended audience for this document is the RIPE ENUM-WG. Once consensus has been reached the intended audience should be expanded to RIPE Services-WG, RIPE DNS-WG, RIPE DB-WG, RIPE Policy-WG, the respective groups of the other RIRs, and/or any other involved parties. Comments to the authors are encouraged. 1. Introduction --------------- In today's internet there is already a large variety of digits-only VoIP devices on the market, also working VoIP-PSTN-gates are available. In the same time there is no registry able to provide for assignments of appropriate telephone numbers according to ITU-T E.164 (i.e. reachable in the international telephone system) and the respective ENUM delegation to the general public. Currently workarounds are being developed (reassignments of geographic-CC numbers, alternative ENUM-trees, non-regional national CC numbers, etc.) resulting in isolated numberspaces, user confusion, and possible future problems resulting from lack of coordination. Because of this current situation there is an immediate need for non-geographic ENUM enabled E.164 UPTS space available for assignments to the general public, and creation of a structure to handle registry tasks, both administrative and operational. 2. Goals -------- The requirements for the registry: - provide undiscriminatory service to the general public (which implies independence towards commercial markets and nations) - provide global service (which implies independence from nations) - provide stable registry and ENUM service - development of policies (which implies the need for some sort of legitimation from the community) The requirements for the number space: - part of the international telephone number space (implies ITU-T E.164) - non-geographic - enduser-specific (UPTS) - fully portable 3. Registry System ------------------ The NRO as the 'community of RIRs', meeting all requirements and already providing a working structure and experience for such a registry, acts as the formal registry (Tier 1) for the assigned ENUM E.164 UPTS space. 3.1 Registry: allocations/assignments ------------------------------------- The RIPE (or a different RIR acting as central coordination point) allocates parts of the assigned ENUM E.164 UPTS space to the RIRs (including itself). The RIRs allocate parts of their respective allocations to their LIRs. LIRs assign numbers from their blocks to endusers. Assignments are enduser-specific (like IPv4 PI), i.e. the allocation to LIRs is just for new assignments, when an enduser changes serviceproviders the authority for the assignment moves with the enduser. 3.2 Registry: database ---------------------- As database for allocations and assignments, whois is used. The whole block assigned by ITU-T is entered as one domain object, with mnt and mnt-lower set to an appropriate maintainer from RIPE (or a different RIR acting as central coordination point). When a block is allocated to a RIR, RIPE creates the respective domain object, entering an appropriate maintainer from the respective RIR as mnt and mnt-lower. When a block is allocated to a LIR, the respective RIR creates the respective domain object, entering an appropriate maintainer from the respective LIR as mnt and mnt-lower. When a number is assigned to an enduser, a maintainer according to the enduser's wishes might be entered. When the enduser changes service providers, a different maintainer can be entered. 3.3 Registry: ENUM ------------------ ENUM delegations are done upon allocation or assignment, i.e.: ITU-T (resp. RIPE acting as Tier 0 for ITU-T) delegates ENUM for the assigned block to RIPE (or a different RIR acting as central coordination point). When a block is allocated to a RIR, the respective ENUM delegations to the RIR are done. The RIR creates its delegations from its database by querying for all most-specific objects (this is important to achieve full portability). 3.4 Registry: ENUM delegation from database ------------------------------------------- RIPE (or a different RIR acting as central coordination point) has to make sure that upon allocation of a block to a RIR, the necessary ENUM delegations are made. As the kind of mechanism used to achieve this doesn't influence procedures in the RIRs, it's only the central coordination point's matter how this is done. But this could be done by the nserver attributes of the domain objects entered upon allocation, and the nameserver configuration could easily be created automatically in such a way. RIRs have to generate delegations in their nameservers from the most specific domain objects. This way the necessary nameserver configuration can be created automatically, isn't dependent on a fixed allocation/assignment length, and provides for full portability. 3.5 Registry: policies ---------------------- A policy for allocation of blocks to the RIRs should be developed in the NRO context. A policy for allocation of blocks to the LIRs and a policy for assignment to endusers by LIRs should be developed by the respective RIR, but common policies (via NRO) might be desirable. All allocations or assignments should be done on request only, a initial automatic allocation of blocks to RIR-members should be deprecated for number space conservation reasons. The assignment policy for LIRs should demonstrate what is considered good practise. Possible norms could regard to the size of blocks assigned to entities (e.g. a fixed assignment length), the number of assignments to entities, and whether an assignment has to be deleted when the enduser is giving it up (i.e. does it have to be available for reassignment by the LIR who initially received the respective block for new assignments or is it ok for the last maintainer/service provider to reuse it?). LIRs receive allocations of blocks from RIRs as a means of moving the work necessary for assignments to the member-level where the request was delivered, and where service is done directly to the enduser. To install some kind of quality assurance, it's proposed to introduce a slow-start mechanism just like with IPv4 PA assignments: initial assignments have to be approved by a RIR hostmaster, until it is decided by the RIR to give the LIR an assignment window, which will be increased when the LIR demonstrated sufficient experience. 4. E.164 UPTS space ------------------- The RIRs request from the ITU-T TSB assignment of non-geographic E.164 UPTS space (i.e. a block under CC878) to the NRO and the respective ENUM delegation to RIPE. It might be worth considering explicitly requesting a short (i.e. 1 digit) prefix to have a number space as large as possible to attenuate ENUM block-delegation issues. I guess the community might like the idea of a sub-block identifier '7' (i.e. +8787 with an 11 digits space) 5. Actions ---------- 1.) discussion in RIPE ENUM-WG on UPTS-space for enduser-assignments handled by RIRs in case of general support of ENUM-WG: 2.) discussion in RIPE ENUM-WG, Services-WG, DNS-WG, and DB-WG on request for registry service (tier 1) operations run by RIPE in case of general support of ENUM-WG and Services-WG: 3.) discussion in RIPE Address Policy-WG on ENUM878x allocation/assignment policies in case of a consensus on (preliminary) policies: 4.) discussion in NRO context (actions 2, 3, and 4 might be intermixed) in case of a consensus on (preliminary) policies: 5.) request to ITU-T TSB for delegation of a non-geographic UPTS block under E.164 CC878 to the RIRs (formally NRO, or RIPE acting in consensus with RIR-community) ----- snap ----- kind regards, Chris Heinze

1 0