- enum-wg - mailman.ripe.net

Seasonal Greetings!
by Carsten Schiefner 20 Dec '07

20 Dec '07

Dear ENUM collegues, happy holidays - shall you have a quiet and relaxing period of time during days ahead with your friends and families. And again: let's then see what will come up for ENUM in 2008 - all the best, Carsten Schiefner RIPE ENUM WG Co-Chair

1 0

Nominet to run the Tier 1 registry for ENUM in the UK for +44
by lesley＠nominet.org.uk 30 Nov '07

30 Nov '07

Hi Everyone, The subject line says it all really.... http://www.nominet.org.uk/news/latest/?contentId=4616 Regards, Lesley

4 3

DNSSEC deployed in the e164.arpa (ENUM) zone
by Anand Buddhdev 26 Nov '07

26 Nov '07

Dear Colleagues, Earlier today, the RIPE NCC signed the e164.arpa (ENUM) zone. The Key-Signing Keys (KSKs) for all zones signed by the RIPE NCC, including the e164.arpa zone, are available at the following secure URL: https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys-new.txt Details of the key maintenance procedure are available at: http://www.ripe.net/rs/enum/key-maint.html If you have any questions, please send an e-mail to <dns-help(a)ripe.net>. Regards, Anand Buddhev DNS Services Manager, RIPE NCC

1 0

Deployment of DNSSEC in the e164.arpa zone
by Anand Buddhdev 20 Nov '07

20 Nov '07

Dear Colleagues, As previously announced, the RIPE NCC will sign the e164.arpa (ENUM) zone on 26 November 2007. Details of the key maintenance procedure are available at: http://www.ripe.net/rs/enum/key-maint.html The Key Signing Key (KSK) will be published on 26 November 2007 at the following secure URL: https://www.ripe.net/projects/disi/keys/ If you have any questions, please send an e-mail to <dns-help(a)ripe.net>. -- Anand Buddhdev, DNS Services Manager, RIPE NCC

1 0

CC1 ENUM LLC End-user Trial Report Published
by Carsten Schiefner 01 Nov '07

01 Nov '07

Dear ENUM colleagues, please find the cover letter at: http://enumllc.com/DC50507650.pdf and the report itself at: http://enumllc.com/USEUTrialRpt.pdf - both are linked from: http://enumllc.com/ustrial.html Best, Carsten Schiefner RIPE ENUM WG Co-Chair

1 0

Nameservers for 9.3.e164.arpa are not responding
by Otmar Lendl 30 Oct '07

30 Oct '07

Luisa, the Italian ENUM tree is currently not operational. This has an impact on everybody who is running ENUM in a production service whenever a customers dials an Italian number. On other words: this outage causes a disruption in communication with Italy. Please fix your nameervers or tell the RIPE NCC to temporarily disable the delegation of 9.3.e164.arpa. Yours, /ol -- / Otmar Lendl <lendl(a)nic.at>, T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg /

1 0

Action Point 55.1 re. RIPE 54 minutes
by Carsten Schiefner 26 Oct '07

26 Oct '07

Dear ENUM-WG colleagues, from yesterday's ENUM WG session the Co-Chairs took the following Action Point 55.1: Co-Chairs to follow up an inconsistency of the action summary with the already approved RIPE 54 minutes: amend the summary appropriately to fit with the body text. This is what the concerned part of the action summary reads now: === (cf. http://www.ripe.net/ripe/wg/enum/minutes/r54-minutes.html) Action Points: CONTINUED ENUM-AP-52.2 [Carsten Schiefner]: NCC correspondence archive -> Working Group list. CLOSED ENUM-AP-53.1 [RIPE NCC]: RIPE NCC to examine and report on "strange queries". ENUM-AP-53.2 [Carsten Schiefner]: Carsten Schiefner to follow up on Quality TF. ENUM-AP-53.3 [Niall O'Reilly]: "NON-REGISTRY issue". NEW ENUM-AP-54.1 [Carsten Schiefner] Think about the task and scope of quality checks and form a new Quality TF. Take this to the list. ENUM-AP-54.3 [Carsten Schiefner]: liaise with ncc-services re correspondence archive. ENUM-AP-54.3 [Niall O'Reilly]: Ask mailing list about having the ENUM WG session in parallel with the AP WG Session at future RIPE Meetings. === After the amendment it will read: === Action Points: CONTINUED ENUM-AP-52.2 [Carsten Schiefner]: NCC correspondence archive -> Working Group list. CLOSED ENUM-AP-53.1 [RIPE NCC]: RIPE NCC to examine and report on "strange queries". ENUM-AP-53.2 [Carsten Schiefner]: Carsten Schiefner to follow up on Quality TF. ENUM-AP-53.3 [Niall O'Reilly]: "NON-REGISTRY issue". NEW ENUM-AP-54.1 [Carsten Schiefner] Think about the task and scope of quality checks and form a new Quality TF. Take this to the list. ENUM-AP-54.2 [Carsten Schiefner]: liaise with ncc-services re DNSMON being also applied to ENUM Tier-1 zones. ENUM-AP-54.3 [Niall O'Reilly]: Ask mailing list about having the ENUM WG session in parallel with the AP WG Session at future RIPE Meetings. === The second last line, starting with "ENUM-AP-54.2" now, will thus correctly reflect what is already minuted under agenda item X. Kind regards, Carsten Schiefner RIPE ENUM WG Co-Chair

1 1

Summary of action items at beginning of RIPE 55 ENUM-WG meeting
by Niall O'Reilly 22 Oct '07

22 Oct '07

Dear ENUM-WG Colleagues, Here for your information is the status of the current action items belonging to the RIPE ENUM WG OPEN ENUM-AP-52.2 [Carsten Schiefner]: NCC correspondence archive -> Working Group list. ENUM-AP-54.1 [Carsten Schiefner]: Think about the task and scope of quality checks and form a new Quality TF. Take this to the list. DONE (and expected to be closed) ENUM-AP-54.2 [Carsten Schiefner]: Liaise with ncc-services re DNSMON ENUM-AP-54.3 [Niall O'Reilly]: Ask mailing list about having the ENUM WG session in parallel with the AP WG Session at future RIPE Meetings. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group

1 0

Discrepancy between minutes and summary of action items from RIPE 54
by Niall O'Reilly 22 Oct '07

22 Oct '07

Dear ENUM-WG Colleagues, I've noticed that the summary of action items doesn't match what is mentioned earlier in the minutes, and suggest a correction below. > Action Points: > > CONTINUED > ENUM-AP-52.2 [Carsten Schiefner]: NCC correspondence archive -> > Working Group list. > > CLOSED > ENUM-AP-53.1 [RIPE NCC]: RIPE NCC to examine and report on "strange > queries". > ENUM-AP-53.2 [Carsten Schiefner]: Carsten Schiefner to follow up on > Quality TF. > ENUM-AP-53.3 [Niall O'Reilly]: "NON-REGISTRY issue". > > NEW > ENUM-AP-54.1 [Carsten Schiefner] Think about the task and scope of > quality checks and form a new Quality TF. Take this to the list. > ENUM-AP-54.3 [Carsten Schiefner]: liaise with ncc-services re > correspondence archive. The item immediately above should read as follows ENUM-AP-54.2 [Carsten Schiefner]: liaise with ncc-services re DNSMON > ENUM-AP-54.3 [Niall O'Reilly]: Ask mailing list about having the > ENUM WG session > in parallel with the AP WG Session at future RIPE Meetings. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group

1 0

Session scheduling for RIPE 55 (and future): ENUM vs AP
by Niall O'Reilly 22 Oct '07

22 Oct '07

From the current draft minutes from RIPE 54: Y. A.O.B. Niall explained that there is pressure to provide more space for the Address Policy WG, and the suggestion was made that there are some WGs whose communities are not be very interested in AP. Are there people here who wouldn't mind this session being parallel to AP. Carsten asked if Niall could send this to the list. ACTION 54.3: Niall O'Reilly to ask mailing list about having the ENUM WG session in parallel with the AP WG session at future RIPE Meetings. The meeting plan for RIPE 55 is currently being discussed among the WG Chairs and the NCC. As of the current draft, scheduling ENUM and Address Policy in parallel seems not to be under consideration, but re- arrangement to deal with other conflicts is likely and may change this. Please speak up, anyone for whom simultaneous scheduling of ENUM and Address Policy WG sessions would be a problem. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group

1 1

Draft Agenda for ENUM WG at RIPE 55
by Niall O'Reilly 22 Oct '07

22 Oct '07

Dear ENUM-WG Colleagues, Apologies for the delay in sending you all this updated agenda for the ENUM working group session at RIPE 55. Please note a related plenary presentation Emergency call handling (A.Mayrhofer) (Grand Ballrooom, 14:00-15:30 session, Tu 23 Oct 2007) ENUM WG session (St John's II, 11:00-12:30, Th 25 Oct 2007) A: Administrivia (5 min: 5/90) Welcome, Scribe, Jabberwok, Microphone etiquette, Agenda B: Note Minutes ENUM-WG of RIPE 54 [Already confirmed on list] C: Review Action List (5 min: 10/90) D: Main presentations (55 min: 65/90) D1: Motivating ENUM: avoiding the bottlenecks (K.Nieminen) D2: Infrastructure ENUM - implementation options for +31 (L.Maris/ P.Nooren) D3: ENUM: a heretic's view on SIP routing (O.Lendl) F: Short News (15 min: 80/90) [ May be curtailed in case of time pressure ] F1: Plan for Signing of E164.ARPA (A.Robachevsky) F2: +44 update (J.Reid) F3: +353 update (C.Daly) G: Discussion on Plenary presentation: Emergency call handling (A.Mayrhofer) [ if additional time for discussion is needed; may be referred to mailing list ] X: Interaction with other working groups (5 min: 85/90) X1: Extension of DNSMON to E164.ARPA (NCC-S & TT WGs) Y: AOB Z: Close (5 min: 90/90) Summary of action items Carsten and I look forward to meeting you all during the week. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group

1 0

DNSMON policy proposal change
by Carsten Schiefner 04 Oct '07

04 Oct '07

Dear ENUM colleagues, Ondrej Sury of CZ.NIC just sent his proposal to widen the DNSMON policy to also monitor ENUM Tier 1 zones to the NCC Services WG mailing list - see below. Please send your comments to the NCC Services WG mailing list directly - this email is intended to be a mere pointer to this discussion thread. Kind regards, Carsten Schiefner RIPE ENUM WG Co-Chair -------- Original Message -------- Subject: [ncc-services-wg] DNSMON policy proposal change Date: Thu, 04 Oct 2007 13:00:07 +0200 From: Ondřej Surý <ondrej.sury(a)nic.cz> Organization: CZ.NIC, z.s.p.o. To: ncc-services-wg(a)ripe.net Hello, I would like this WG to discuss following proposal to change DNSMON policy. I am also attaching new document (ripe-342-1.txt), and diff between this and current policy (ripe-342.diff). Number: TBD Policy Proposal Name: Allow DNSMON services to monitor ENUM domains Author: a. name: Ondrej Sury b. e-mail: ondrej.sury(a)nic.cz c. organisation: CZ.NIC, z.s.p.o. Proposal Version: 1.0 Submission Date: 2007-08-01 Suggested RIPE Working Group for discussion and publication: ncc-services Proposal type: modify Policy term: permanent Summary of proposal: Policy text: a. Current: see ripe-342.txt b. New: see ripe-342-1.txt Rationale: a. Arguments supporting the proposal ENUM domains are already monitored by DNSMON on request when country ENUM administrator is also ccTLD registry. This proposal formalized this and also allows country ENUM administrators to request such service in case they are not ccTLD registry. b. Arguments opposing the proposal Only one argument was raised during discussion from Jim Reid which oppose idea of NCC doing non-core services for their members. -- Ondřej Surý technický ředitel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americká 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- DNS Monitoring Service for TLD Administrators Service description Daniel Karrenberg, Ruud de Kooter, Henk Uijterwaal RIPE NCC Document ID: ripe-342 Date: 22 February 2005 0. Definitions a. TLD: Top Level Domain, as recorded by the IANA. b. ENUM domain: Delegated domain corresponding to E.164 country codes, as delegated by RIPE NCC. b. TLD Administrator: The organisation(s) responsible for the registry of a TLD or ENUM domain. 1. Introduction The Domain Name System (DNS) is a hierarchical and distributed database that translates domain names into IP addresses. Almost every application on the Internet uses DNS; it is a key element in the Internet infrastructure. At the top of the DNS hierarchy, there are thirteen root servers, known as a.root to m.root. These are located at various places all over the world. For the DNS service to work properly, two things are essential: the server machines should be working correctly and the clients using the server should be able to reach it through the network. Monitoring the latter is difficult, as the clients can be thousands of kilometres and a few dozen network hops away. The RIPE NCC has offered the Test Traffic Monitoring (TTM) Service as a membership service since late 2000. For the TTM service, we installed measurement probes (called Test Boxes or TBs) at sites all over the world. The operators of these sites are usually referred to as "Test Box Hosts''. The original idea was to use these TBs to measure performance between sites hosting a TB. In early 2003, it became clear that the boxes could also be used to monitor the performance of other services, for example DNS. We developed software to carry out these measurements, giving sites hosting Test Boxes an overview of the connectivity to each of the root servers. This feature is called DNSMON. By grouping the data collected for DNS by root server, instead of by TB, it is possible to obtain an overview of the connectivity of the root server itself. While this may not be of interest to the Test Box Hosts, it is very interesting to the operator of the root server. It provides an overview of the connectivity of their server measured from more than 100 locations. By combining the data with topology information it can give a strong indication of the location of a connectivity problem. We also realised that this technique was not limited to the root servers but that we could also apply it to TLD servers. The ccTLD community expressed strong interest in doing this. This resulted in the development of the DNSMON service. ENUM operators also expressed interest in monitoring their DNS servers and in fact some of ENUM zones are already monitored. DNSMON provides a comprehensive, objective and up-to-date overview of the quality of the service offered by high-level DNS servers. Currently these are the root servers and some interested TLD administrators' servers. DNSMON is built on top of the TTM infrastructure. The service has already been running in test mode for several months. The RIPE NCC will offer this as a production service in early 2005. The main users of the DNSMON data will be * the Test Box Hosts, * the operators of the root servers, TLD and ENUM domain servers, * the Internet community in general. In the first two cases, the users of the data will often rely on it for their daily operations and will need technical support for the service. The RIPE NCC will incur additional costs to provide this support and will need to recover these costs. This generates certain expectations for the quality, reliability and support of the DNSMON service. In case of the Test Box Hosts, a formal agreement [RIPE297] describing the responsibilities and obligations of both parties exists. As DNSMON is another instance of a network performance related measurement, RIPE297 covers the DNSMON service as well and there is no need to sign a new contract with the TB Hosts. This paper meets the need for a similar document for TLD Administrators. The outline of the remainder of this document is as follows: Section 2 contains an informal overview of the service and explains what a TLD Administrator can expect when subscribing to the service in plain language. Section 3 and the appendices contain the text of the contract that will have to be signed when a TLD Administrator subscribes to the DNSMON service. 2. Global description of the service There are two components in the DNSMON setup: 1. The Test Boxes. These monitor the DNS servers by sending queries to them. 2. The central machine that collects the data from the Test Boxes generates plots and presents them to the users. Only the central machine is under the direct control of the RIPE NCC in this set up. The RIPE NCC aims to ensure that this machine is always working correctly. The TB hosts, not the RIPE NCC own and operate the TBs. If a TB is down, it will not collect data. In this case, the central machine will be unable to present data from this particular TB. The RIPE NCC monitors the performance of the TBs, notifying any problems on a daily basis. Fixing problems requires effort from the host. It is reasonable to expect that sites hosting a TB would respond to such requests - as they are interested in the data and pay the RIPE NCC a fee for collecting it. This, however, is beyond the control of the RIPE NCC. When subscribing to the DNSMON service, a TLD Administrator can expect: 1. As many TBs as possible will be used to monitor the servers of that TLD or ENUM domain during a given time period. 2. Early access to the data. The TLD Administrators will have access to the data as soon as it is collected, the public will only have access to the data after two hours. This gives the TLD Administrator an opportunity to solve problems. TLD Administrators will also have posting rights to a mailing list, used to inform the public of problems, solutions and work-rounds. 3. Help desk support. In case of a problem, the TLD Administrator will be able to contact the RIPE NCC who will try to resolve the problem with the service as soon as possible. In addition, when "unusual" effects are seen in the data, the RIPE NCC will help the TLD Administrator to investigate them. The RIPE NCC incurs additional costs to offer these services. These costs will be charged to the TLD Administrators. A TLD Administrator using this service and hosting a TB, will not have to pay a service fee for the TB. The RIPE NCC will include the servers of a TLD or ENUM domain in the service if that TLD Administrator asks for it. Servers of a TLD or ENUM domain may be included even if the TLD Administrator does not ask for it. The hosts of the TBs located inside a TLD may also ask for the TLD or ENUM domain servers to be monitored. A TLD Administrator that did not ask for its servers to be monitored will not have access to the services listed above. As the DNSMON service is built on top of the TTM infrastructure, the data disclosure policy for the TTM service also applies to DNSMON. The current version of this policy can be found in document RIPE300. This policy specifically means that: * A TLD Administrator can show all results of the DNSMON service to their customers. * The TLD Administrators, the TB hosts and the RIPE NCC can freely show all results at a RIPE Meeting. * A TLD Administrator can only show results of the DNSMON service related to its domain to the general public without peer review. Similarly a TB host can only show results obtained by the TB at its site to the general public. For all other publications, a draft of the publication has to be circulated amongst the participating sites for review before publication. It is recommended that the data is published as anonymously as possible. Subscribing to this service generates certain expectations from both sides and results in the transfer of money. In order to formalise the relationship and to ensure that both sides understand their obligations, it is proposed to sign a "DNS Monitoring Service Agreement". The text of this document is included in the next section. The service will start after both sides have signed this agreement. 3. DNS Monitoring Service Agreement Note: This section and the appendices contain the text of the formal agreement between the TLD Administrators and the RIPE NCC. When the former decides to use the service, a separate contract will be drawn up for both parties to sign. The text of this contract will be identical to section 3 and the appendices of this document, with names and dates filled out. [TLD Administrator + address + postal code + city + country] >From here on referred to as "the TLD Administrator", and The Reseaux IP Europeens Network Coordination Centre Singel 258 1016 AB Amsterdam The Netherlands, >From here on referred to as "the RIPE NCC". Whereas: The RIPE NCC has developed a service to monitor the performance of DNS servers called DNSMON. This service is described Appendix A. The TLD Administrator wishes to use this monitoring service and wants to obtain early access to the data collected by the DNSMON service along with a help desk for this service. This is described in detail in Appendix C. The RIPE NCC membership requires receiving partial financial compensation for the operation of the DNSMON monitoring of the NN TLD or ENUM Domain from the TLD administrator. 3.1. Definitions a. TLD: Top Level Domain, as recorded by the IANA, or delegated domain corresponding to E.164 country code, as delegated by RIPE NCC. b. TLD Administrator: The organisation(s) responsible for the registry of a TLD. c. TTM service: Test Traffic Measurements Service, as described in RIPE Documents 209 and 297. d. Test Box/TB: probes monitoring the DNS servers by sending queries to DNS servers and analyzing the results e. DNSMON: A service monitoring the performance of DNS servers designated by TLD Administrators, the RIPE NCC or the TB hosts, by the TBs. The results are collected and published in graphical form on http://dnsmon.ripe.net. These results will be made available to TLD Administrators and the general public. f. Software: Software as specified in Annex A to be used for DNSMON, including any upgrades. 3.2. Start of the agreement a. The DNSMON Service Agreement between the RIPE NCC and a TLD Administrator shall come into effect by means of an offer and an acceptance. b. The TLD Administrator shall send the RIPE NCC at least two hard copies of this agreement, with the appropriate sections filled out, signed by an authorised representative of the TLD Administrator, as well as an extract from the Commercial Trade Register or similar document proving the TLD Administrator's business with the national authorities. (The latter is not necessary for TLD Administrators who are already RIPE NCC customers for TTM or Registration Services.) When the documents arrive at the RIPE NCC, a representative of the RIPE NCC shall sign the documents and return at least one copy to the TLD Administrator. The RIPE NCC shall not commence the provision of the DNSMON service until a signed version of the agreement has been received by the RIPE NCC. 3.3. Scope of the Agreement a. The RIPE NCC will monitor the authoritative DNS servers serving the NN TLD and servers designated by the TLD Administrator. b. Upon signing this agreement, the TLD Administrator acknowledges and accepts that it has obtained the right to use and the obligation to pay for the DNSMON service in accordance with this agreement, as specified further in Annex B. c. Upon signing this agreement, the RIPE NCC acknowledges that it has to provide the DNSMON service to the TLD Administrator, as specified further in Annex A and C. If the RIPE NCC cannot provide the service it will not charge the service fee for the period that the service was not available, see Annex A for details. d. The TLD Administrator can designate the servers, serving the NN TLD, to be monitored by the RIPE NCC. An initial list will be provided with this agreement (see Annex D); this list can be changed at any time with at least three full working days notice. The RIPE NCC will confirm any changes to this list during this period. e. The TLD Administrator and the RIPE NCC will designate administrative, technical and billing contacts for the execution of this agreement, as further specified in Annex C. f. The RIPE NCC and the TLD Administrator shall follow the operational procedures described in this Agreement and as further specified in Annex C. g. The RIPE NCC will offer e-mail help desk support to the TLD Administrator as further specified in Annex C. h. The RIPE NCC provides facilities to announce and communicate technical issues to technical contacts of the TLD Administrator as further specified in Annex C. 3.4. Changing the agreement All changes and amendments to this agreement have to be agreed upon by both parties before they come into effect. When this agreement is changed, the RIPE NCC will send the modified text to the TLD administrator. 3.5. Management, maintenance and support The DNSMON Service is operated and maintained under the sole administrative control of the RIPE NCC, including software upgrades, software configuration and system administration. The RIPE NCC will first present any plans for the DNSMON service for discussion in the RIPE DNS Working Group. The same working group can be used by the TLD Administrators to provide feedback on the services and suggestions for improvements. The RIPE NCC will, in its annual activity plan, announce the final plan for the service for the next calendar year. 3.6. Assignment The parties shall not assign, transfer, charge or deal in any manner with this agreement or any rights under it, without prior written consent of the other party. 3.7. Confidentiality and Publicity a. Without prejudice to subsections (b) to (e), each party shall treat as private the other party's confidential information. Confidential information includes any information relating to the service and any information imparted by the other party as being confidential. Confidential information shall not include information that has become public knowledge other than through violation of this duty of confidentiality. b. The RIPE NCC will publish the results of the monitoring of the authoritative DNS servers serving the domain(s) of the TLD administrator and the servers designated by the TLD administrator to the general public. c. Both the TLD Administrator and the RIPE NCC may publish the data collected by the DNSMON server and make statements about the data (written or oral, press releases and interviews included). All public statements about the data will be subject to the data disclosure policy as described in document RIPE300. The DNSMON data is considered to be part of the TTM data. d. Each party shall inform the other party about (public domain) publications that use the DNSMON data. e. The RIPE NCC will provide a technical description of the service that can be used by the TLD Administrator in public statements. 3.8. Liability; Indemnification a. The TLD Administrator shall be liable for all aspects of its use of the DNSMON service offered by the RIPE NCC. b. The TLD Administrator shall indemnify and protect the RIPE NCC from and against any damages and expenses, including related legal fees that may result from a third party claiming compensation for loss or damage caused in whole or in part by non-performance or any act or omission by the TLD Administrator or its employees. c. In no event does the DNSMON service provide a guarantee with respect to the performance of any DNS servers. The RIPE NCC shall not be liable for any damage caused by reduced or non-performance of DNS servers or by any acts or omissions by the TLD Administrator in consequence of RIPE NCC performing DNSMON services. d. The RIPE NCC shall not accept liability for: * mutilation or loss of DNSMON Data or other data during transmission or when stored on TLD Administrator's computers; * the results and consequences of analysis of DNSMON Data undertaken by the RIPE NCC; * the consequences of any modification or adaptation to the Test Box or Software made by a Test Box Host or from the combination of the Test Box or Software with hardware or software other than that prescribed in the Hardware and Software Requirements in RIPE297. e. The RIPE NCC shall not be liable for any damage caused by a Test Box, the DNSMON Software or any failure to meet any of its obligations under this Agreement, except where such damage or failure is due to a grossly negligent or wilful act or omission by the RIPE NCC managing personnel. f. In no event shall the RIPE NCC be liable for indirect damages, including damage to the TLD Administrator's business or loss of profits. g. In no event shall the liability of the RIPE NCC in connection with this Agreement exceed the Service Fee invoiced in respect of the calendar year in which the damage first occurred. The maximum shall apply per event or series of connected events resulting in such liability. h. Without prejudice to any other provision in this Article, the RIPE NCC shall not be liable for damage as a result of a failure to meet any obligation under this Agreement if such failure is due to circumstances for which the RIPE NCC is not considered accountable according to law, contract or trade custom. The RIPE NCC in any event shall not be accountable for failures to perform resulting from interruptions or improper functioning of power or telecommunication services facilities. 3.9. Termination a. This Agreement shall be valid as from the date of signature including the information to be filled in by the TLD Administrator in Annex A and C. b. Each party may terminate this Agreement I. By giving thirty days written notice. This must be sent by registered post with advice of delivery; II. With immediate effect upon written notice to the other party (by registered post with advice of delivery) in the event of a substantial breach by either party of any obligation under the Agreement which is irremediable or which is not remedied within a reasonable period of time, following written notice requesting it be remedied; III. With immediate effect upon written notice that the other party has filed or plans to file for bankruptcy or be declared bankrupt or plans to apply for a suspension of payment or order the liquidation of its organisation in any manner whatsoever. c. The RIPE NCC may terminate this agreement if the TLD Administrator does not pay the service fee according to the procedure described in Annex B. d. Any payments or credits outstanding upon termination remain due. e. Upon termination, each party shall ensure that all confidential information and software belonging to the other party (in whatever medium it is recorded or held) is returned, deleted or destroyed in accordance with the other party's written instructions. f. Upon termination, the RIPE NCC ensures availability of data for two years, though data may be removed from publicly accessible web and ftp sites. 3.10. Variation of Terms a. In the event that any of the terms of the agreement (including Annexes) is determined by any competent authority to be invalid, unlawful or unenforceable, such term will be removed from the remaining terms which continue to be valid to the fullest extent permitted by Dutch law. b. The "RIPE NCC Standard Terms and Conditions" (document RIPE321) apply. In the event that there is a conflict between this document and the RIPE NCC Standard Terms and Conditions, the agreements in this document take precedence. 3.11. Applicable law; jurisdiction a. The agreement shall be governed exclusively by Dutch law. b. The competent court in Amsterdam shall have exclusive jurisdiction in all matters relating to the agreement. c. However, in the event of non-payment of the service fee, the RIPE NCC shall have the right to bring proceedings before the competent court in Amsterdam or the competent court in the seat of the TLD Administrator." RIPE NCC By: _________________________________________ Printed Name: _________________________________________ Company: _________________________________________ Title: _________________________________________ [TLD Administrator]: By: _________________________________________ Printed Name: _________________________________________ Company: _________________________________________ Title: _________________________________________ Annex A Specification of the DNSMON service 1. The goal of the DNSMON service is to monitor DNS servers selected by TLD Administrators, the RIPE NCC or the Test Box Hosts. After signing this document: The RIPE NCC shall make an effort to monitor the servers of that TLD by as many TBs as possible. 2. The RIPE NCC shall make every effort to provide early access to the data: The TLD Administrators as soon as it is collected, the public after two hours. This gives the TLD Administrator an opportunity to solve problems. TLD Administrators will also get posting rights to a mailing list to inform the public of problems and solutions. 3. The RIPE NCC will provide help desk support for the service: In case of a problem, the TLD Administrator will be able to contact the RIPE NCC, who will try to solve the problem with the service as soon as possible. When "unusual" effects are seen in the data, the RIPE NCC will help the TLD Administrator to investigate. Software 1. The RIPE NCC will use the DNSMON software developed in house for monitoring. 2. The source code of the software for the service will be made available under the GNU General Public Licence ("GPL") on a CVS server (see http://www.gnu.org/licenses/gpl.txt for details). 3. Bugs can be reported to the RIPE NCC and will be fixed in a timely fashion. 4. Feature requests will be implemented by the RIPE NCC on a best effort basis. Non-availability of the service The service is considered not to be available if: * the number of TBs that monitors the servers of a TLD is lower than ten, * no data can be collected due to problems with the central machine for more than one week, * the help desk cannot respond to customer queries for more than three days. In these cases, and only in these cases, the RIPE NCC will refund the service fee for the period that the service was not available. Technical description of the service A technical description of the DNSMON service is available at: http://dnsmon.ripe.net/dns-servmon/information. Annex B: Billing scheme and procedure The TLD Administrator shall for contribution purposes self-declare to the RIPE NCC a category size of SMALL, MEDIUM or LARGE by stating this in the DNSMON agreement. Guidelines for the charging category can be the number of registered sub-domains, the number of additional DNS servers that need to be monitored by DNSMON and the load that is expected on the DNSMON service team. Also the already declared size of other TLD Administrators may be helpful. The RIPE NCC will publish the fact that a TLD Administrator supports the operation of DNSMON including the current self-declared category size of a TLD Administrator on the DNSMON web site. Only TLD Administrators in the MEDIUM and LARGE category may designate additional DNS servers to be monitored by DNSMON during the calendar year at any time. TLD Administrators in the SMALL category can replace the server(s) monitored once during the year. The TLD Administrator can request a change in category size up to 31 March. This change will be granted unless the TLD Administrator had more DNS servers to be monitored by DNSMON and requests to be shifted into the SMALL category. The DNSMON Service fees shall be as follows: Category size Amount SMALL EUR 2,000 per year MEDIUM EUR 4,000 per year LARGE EUR 6,000 per year Note: a TLD Administrator hosting a RIPE NCC Test Box as well will not be charged the service fee for the Test Box. Payment scheme 1. The TLD Administrator shall owe the RIPE NCC the service fee listed above, excluding Dutch VAT or any applicable taxes, immediately due when the TLD Administrator concludes the agreement. Dutch VAT will be charged to TLD Administrators inside the EU unless a valid EU VAT number is provided by the TLD Administrator. 2. The RIPE NCC reserves the right to update the service fee annually to reflect changes to the operational costs of the service. Changes will be announced at least one month in advance by e-mail to billing and technical contacts of the service. 3. Invoices for the relevant financial (1/1 to 31/12) year will be generated and sent via e-mail and postal mail at the beginning of April. At the request of the TLD Administrator a copy of the invoice can be sent by e-mail to the contact. Payment is due 30 days after date of invoice. The first reminder is sent via postal mail and e-mail 31 days after date of invoice. If the RIPE NCC does not receive payment within 60 days of the date of invoice, a second reminder including a late payment fee of EUR 50 is sent to the registry. After 90 days of non-payment the DNSMON service for the TLD Administrator is revoked. The DNSMON service will only be reinstalled after the TLD Administrator has paid all outstanding invoices. 4. The RIPE NCC withholds the right to charge the TLD Administrator pro-rata for any third party expenses incurred regarding the agreed services. 5. The TLD Administrator's obligation to perform its payment commitments shall commence on the day on which the DNS Monitoring Services Agreement is signed. 6. As soon as this agreement is concluded, the RIPE NCC shall send the TLD administrator an invoice covering the period until the end of the financial year. 7. The TLD Administrator may not postpone its payment obligations or offset any of its legal or financial claims against the RIPE NCC. Annex C: Operations Operational Contacts The RIPE NCC help desk will be available by e-mail, Monday to Friday between 10:00 and 16:00 Amsterdam time (GMT+1 or GMT+2) except for on Dutch public holidays. A current list of public holidays is available on the RIPE NCC website. An initial response to e-mails will be given during the first working day after receipt of an e-mail. This response may be by e-mail or telephone. RIPE NCC <TLD Administrator> Helpdesk/ NOC dnsmon(a)ripe.net Emergency contact ops(a)ripe.net Finance/ billing contact finance(a)ripe.net TLD Technical Contact -- Both the RIPE NCC and the TLD Administrator will inform each other about any changes to the operational contacts as soon as possible, preferably before the new contact detail(s) come in to effect. Announcements The RIPE NCC will make a mailing list available to announce and communicate technical issues to technical contacts of the TLD Administrators. Technical contacts of the TLD Administrators will be automatically subscribed to dnsmon-contact(a)ripe.net. The RIPE NCC will make available a public mailing list to discuss the results of the monitoring. Posting rights will be limited to the RIPE NCC, technical contacts of the TLD Administrators, technical contacts of TBs and others to be decided by the RIPE NCC. Announcements, in regards to the monitoring service, to the public will be published to dnsmon-user(a)ripe.net list. Presentation and availability of DNSMON monitoring data DNSMON monitoring results will be published in graphical format on http://dnsmon.ripe.net The RIPE NCC will make the raw data ("numbers that went into the plots") available on its ftp server for the TLD Administrator on request. The RIPE NCC collects the data from the TBs with an average expected 30 minutes lag between measurement and collection. If there are connectivity problems with a TB, this may be longer. The RIPE NCC will update results retroactively if there are major changes. Data that could not be collected for two weeks will not be processed. The RIPE NCC will analyse the collected data and make the results available to the TLD Administrator. The TLD Administrator will have restricted access for the first two hours after the measurement, provided the data could be collected. Unlimited access to the data will be given two hours after the measurement, regardless whether the data was made available for restricted access before or not. The RIPE NCC will only check that plots have been created correctly, it will not check the plots for any unusual events nor will it report on such events. It is the responsibility of the TLD Administrator to study the plots. The RIPE NCC may make the raw data collected by the services available to researchers for scientific and statistical analysis. The RIPE NCC will maintain the software. Bugs will be fixed in a timely fashion. New features will be added, depending on available resources. The RIPE NCC will present its development plans and report on the service during the DNS Working Group sessions held at RIPE Meetings. The server for the DNSMON site is monitored continuously. A backup server for the DNSMON site is available. It will be enabled when there is a problem with the primary server. The outage of the service will be of the order of one hour or less. If the data on the disks of both servers is corrupted and has to be restored from a backup tape, restoring the service will start on the following working day and can take up to twelve hours. Upon termination of this contract, the RIPE NCC will ensure availability of data for two years, though such data may be removed from any website. Annex D: Initial list of servers to be monitored Domain Date Server (Hostname) Server (IP Address)

2 2

ENUM for +48
by Andrzej Bartosiewicz 03 Oct '07

03 Oct '07

Our regulator officially announced public consultation for new User ENUM registration rules (proposed by NASK) for +48. The main differences to the existing rules are: 1. carrier approval is not necessary for domain name registration 2. validation should be done by Registrar (SMS for mobile, documents for PSTN and assigned blocks for PBX 3. CRUE for carriers 4. If case central database for "Number Portability, Caller Location for Emergency Services and Central Database of Telephony Subscribers" is implemented, User ENUM registry system will be integrated with this system. Document is available in Polish only. http://www.uke.gov.pl/uke/index.jsp?place=Lead07&news_cat_id=168&news_id=246 9&layout=3&page=text I will keep you informed on the progress of consultations and the (positive...) result. Best, Andrzej Bartosiewicz tel: +48.22.380.8395 tel: +1.310.817.6567 ENUM: 0.7.5.1.4.2.6.0.6.8.4.e164.arpa skype: abartosiewicz

1 0

Deploying DNSSEC in e164.arpa zone
by Andrei Robachevsky 01 Oct '07

01 Oct '07

Dear Colleagues, The RIPE NCC is pleased to announce its plan for the deployment of DNSSEC in the e164.arpa zone (ENUM). This improvement to the operation of the domain was developed and concluded following consultation with the IETF's Internet Architecture Board (IAB). In line with the IAB's instructions, the RIPE NCC has provided technical administration for the e164.arpa zone since 2002. These instructions are documented and are available at: http://www.ripe.net/enum/instructions.html We informed the IAB of our intention to implement DNSSEC in the e164.arpa zone and we received positive feedback and support for the deployment. Details of the correspondence between the RIPE NCC and the IAB can be found at: http://www.iab.org/documents/correspondence/ We will start signing the e164.arpa on 26 November 2007 and support for secure delegations will be provided on 24 March 2008. Further announcements will be posted as these milestones approach. Best regards, Andrei Robachevsky Chief Technical Officer RIPE NCC

6 11

Draft agenda for ENUM WG at RIPE 55
by Niall O'Reilly 24 Sep '07

24 Sep '07

Dear ENUM-WG colleagues, I'm very glad to send you the draft agenda for the ENUM WG at RIPE 55. Please note that the presentation on Emergency Call Handling will take place during one of the plenary sessions, whose time and date are yet to be determined. A: Administrivia (5 min: 5/90) Welcome, Scribe, Jabberwok, Microphone etiquette, Agenda B: Note Minutes ENUM-WG at RIPE 54 [Already confirmed on list] C: Review Action List (5 min: 10/90) D: Main presentations (55 min: 65/90) D1: Motivating ENUM: avoiding the bottlenecks (K.Nieminen) D2: Infrastructure ENUM - implementation options for +31 (L.Maris/ P.Nooren) D3: [to be announced when confirmed] F: Short News (15 min: 80/90) F1: +44 update (J.Reid) [other items of short news may arise] G: Discussion on Plenary presentation: Emergency call handling (R.Schischka/A.Mayrhofer) [if additional time for discussion is needed] X: Interaction with other working groups (5 min: 85/90) Y: AOB Z: Close (5 min: 90/90) Summary of action items I look froward to seeing you all in Amsterdam in four weeks' time. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group

1 0

Dutch SIPSIG Infrastructure ENUM on 11 October 2007
by Schiefner, Carsten 12 Sep '07

12 Sep '07

Dear ENUM colleagues, the dutch ISOC chapter has annonced an Infrastructure ENUM event on 11 October 2007 at the Royal Library ("Koninklijke Bibliotheek") in The Hague. Chaired by Richard Shockey (chair of IETF ENUM WG), this event shall cover the where-abouts of Infrastructure ENUM - technically as well as organisationally: - What is the future of the federational model? - The likelihood of a speedy development of "federations of federations" - Or will the "multiple root" situation prevail, at least for the foreseeable future? Speakers, amongst others, are Douglas J. Ranalli, Eli Katz and Steve Heap. Admission is free. More information is available at: http://isoc.nl/activ/2007-SIPSIG-infrastructureENUM.htm On SIPSIG in general: http://isoc.nl/organisatie/internettelefonie Both possibly in Dutch only - I can't check right now. Given the rather international scope of the topic and list of speakers, I would assume that the event is conducted in English - I have no concrete information on this, though. Best regards, Carsten Schiefner -- Deutsche Telekom Technischer Service GmbH Zentrum Technischer Kundendienst Carsten Schiefner SG4 - Service Gestaltung IP-/ATM-Vorprodukte Ammerländer Heerstr. 138, D-26129 Oldenburg +49 441 234-4571 (Tel.) +49 431 7163-3972 (Fax) +49 151 14525458 (Mobil) <<mailto:Carsten.Schiefner@telekom.de>> <<http://www.telekom.de>> Deutsche Telekom Technischer Service GmbH Geschäftsführung/Management board: Dr. Roland Folz (Vorsitzender), Otto Neuhoff Handelsregister/Commercial register: Amtsgericht Bonn HRB 14189 Sitz der Gesellschaft/Corporate seat: Bonn

1 0

ENUM will discontinue in Switzerland (+41)
by Bernie Hoeneisen 04 Sep '07

04 Sep '07

Dear RIPE ENUM WG The authorisation to run the ENUM Registry for CC 41 granted by OFCOM expires on 30 September 2007. On the basis of the framework conditions in Switzerland it is not possible for SWITCH to continue in the role of ENUM Registry. This means the ENUM service for 1.4.e164.arpa will be discontinued. Please find more information in our News Item on: http://www.switch.ch/about/news.html?id=148 Note, that this is due to the specific situation in Switzerland, and shall not be taken as a bad sign for ENUM in general! Best Regards, Bernie Hoeneisen, SWITCH, Project Manager ENUM

1 0

Dutch ENUM day on 25 September 2007
by Carsten Schiefner 28 Aug '07

28 Aug '07

Dear ENUM colleagues, ECP.NL, the dutch ISOC chapter and ENUM.NL, the Netherlands' ENUM registry for 1.3.e164.arpa, will hold an ENUM Day on 25 September 2007 in Utrecht. There will be three workshop tracks in the morning re. technology, policy and usage. The afternoon will cover an informal agenda with explanations on ENUM considering best practices, demonstrations and presentations and be rounded off with discussions on the possibilities that ENUM offers. Please find more information (only in Dutch) at: http://www.enuminnederland.nl/ Best regards, Carsten Schiefner

1 0

Czech ENUM day on 12 September 2007
by Carsten Schiefner 28 Aug '07

28 Aug '07

Dear ENUM colleagues, only a week and a bit later, CZ.NIC, the Czech Republic's ENUM registry for 0.2.4.e164.arpa, will hold its 1st ENUM Day on 12 September 2007 in Prague. Agenda (subject to change): . 8.15 Registration . 9.00 Introductory word Ondřej Filip /CZ.NIC, z. s. p. o. . 9.05 What is ENUM, view to the future Jiří Peterka /CZ.NIC, z. s. p. o. . 9.20 ENUM, 1st year in the Czech Republic Ondřej Filip /CZ.NIC, z. s. p. o. . 9.30 ENUM Ready Pavel Tůma /CZ.NIC, z. s. p. o. . 9.45 ENUM implementation to the Netway network Martin Semrád /NETWAY.CZ s. r. o. . 10.05 ENUM in the CESNET network Jan Růžička /CESNET . 10.25 Coffee break . 11.00 Regulation of VoIP Michal Frankl /The Czech Telecommunication Office . 11.20 Personal information in the registration process Martina Šnajderová /The Office for Personal Data Portection . 11.35 Case study - Asterisk in CZ.NIC network Ondřej Surý /CZ.NIC, z. s. p. o. . 11.50 IP phones in academy network Tibor Weis /Technical university in Zvolen . 12.10 Lunch break . 13.00 Barrieries in ENUM implementation Jiří Kuthan /IPTEL GmbH/Tekelec . 13.15 ENUM in Innovaphone products Milan Stehlík /Annex NET, s. r. o. . 13.30 VoIP and ENUM products in ASUS and WELL Karel Mišurec /JOYCE ČR, s. r. o. . 13.45 ENUM in neighbour countries, Germany Heike Schmidt-Henkel /DENIC eG . 14.00 ENUM in neighbour countries, Austria Robert Schischka /NIC.AT . 14.15 Panel discussion . 15.00 Public discussion The price of a ticket for the all-day ENUM Day Conference is 200 CZK. Please find more information at: http://www.nic.cz/en/about-us/page.php?aid=439&sid=16&wid=1 and http://enum.nic.cz/enumday/?lang=en and Best regards, Carsten Schiefner

1 0

German ENUM day on 3 September 2007
by Carsten Schiefner 28 Aug '07

28 Aug '07

Dear ENUM colleagues, apologies for this being on rather short notice. DENIC, Germany's ENUM registry for 9.4.e164.arpa, will hold its 9th ENUM Day already next Monday, on 3 September 2007. The preliminary schedule as of today is: . 10:00 Welcome Adress (Andreas Bäß, DENIC) . 10:15 ENUM VoIP Island-Interconnect: Is there a life after Phone Call Charges? (Wilhelm Wimmreuter, freelance ITC consultant) . 11:00 Avoiding SPAM calls over IP telephony (Stefan Liske, University of Potsdam) . 11:30 TeamSIP and ENUM - two complementary solution concepts (Dr. Thomas Kupec, TeamFON) . 12:00 Lunch break . 13:30 ENUM-based Softswitch Requirement (Lawrence Conroy, Roke Manor Research) . 14:00 Recent developments of ENUM at RIPE (Carsten Schiefner, RIPE ENUM WG) . 14:30 How to combine ENUM, Number Portability, Caller Location for Emergency Services and Central Database of Telephony Subscribers? (Andrzej Bartosiewicz, NASK) . 15:15 Coffee break . 15:45 NGN Voice and Carrier Interconnection for IMS and non-IMS based Architectures (Hans Mathys, Cisco Systems) . 16:30 Status report from the IETF: Infrastructure ENUM and SPEERMINT (Otmar Lendl, nic.at) As always, attending is free of charge. Please find more information at: http://www.denic.de/en/enum/allgemeines/veranstaltung/ENUM-Tag.html#TM_03_0… In order to register for the ENUM day, please use the web form at: http://www.denic.de/xml/eventform/enum.php Best regards, Carsten Schiefner

1 0

First call for RIPE 55 ENUM WG agenda
by Niall O'Reilly 20 Aug '07

20 Aug '07

Dear ENUM-WG participants, I've been reminded that we are nine weeks away from RIPE 55 (22-26 October in Amsterdam) and that time will fly. I'm looking for input from you all for the agenda of the ENUM WG for this meeting: offers to give presentations, suggestions for presentations from others, and warnings of topics to avoid for lack of interest. To begin with, and still needing work by your Co-Chairs to engage the 'likely suspects', here is my current list of likely topics. - Updates from countries with 'significant' developments; - DNAME-based interim solution for infrastructure ENUM; - ENUM in production: operations, uptake, strategy. I'm looking forward to seeing as many of you as possible in Amsterdam! Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group

1 0

DNS provisioning system maintenance, 22 Aug
by Sjoerd Oostdijck 16 Aug '07

16 Aug '07

Dear Colleagues, On Wednesday, 22 August 2007 we will upgrade the provisioning system for our DNS servers. There will be no zone updates between 09:00 and 11:00 (UTC) on that day. We apologise for any inconvenience this may cause. If you have any questions or concerns about this, please send an e-mail to dns-help(a)ripe.net Regards, Sjoerd Oostdijck, DNS Services RIPE NCC

1 0

Delegation of +370/0.7.3.e164.arpa completed
by Carsten Schiefner 13 Aug '07

13 Aug '07

Dear colleagues, the ENUM delegation request for 0.7.3.e164.arpa - +370 is Lithuania's E.164 CC - was confirmed by ITU-T TSB on 6 Aug 2007. As per 10 Aug 2007, 0.7.3.e164.arpa is delegated to enum.rrt.lt. [195.182.71.240] app.numeris.lt. [81.16.239.13] 0.7.3.e164.arpa becomes the 44th ENUM delegation. Welcome, Lithuania! :-) Best, Carsten Schiefner (RIPE ENUM WG Co-Chair)

1 0

DNS provisioning system maintenance, 8th Aug
by Sjoerd Oostdijck 02 Aug '07

02 Aug '07

Dear Colleagues, On Wednesday, 8 August 2007 we will update the provisioning system for our DNS servers. There will be no zone updates between 08:30 and 09:30 (UTC) on that day. We apologise for any inconvenience this may cause. If you have any questions or concerns about this, please send an e-mail to <dns-help(a)ripe.net>. Regards, Sjoerd Oostdijck, DNS Services RIPE NCC

1 0

Minutes RIPE 54 ENUM WG
by Niall O'Reilly 17 Jul '07

17 Jul '07

Dear ENUM-WG Members, Draft Minutes of the ENUM WG session at RIPE 54 were made available on 8 June by RIPE NCC at http://www.ripe.net/ripe/wg/enum/minutes/r54- minutes.html. Thanks in particular to Alex le Heux and Susannah Gray. Please inspect this draft and send corrections or other comments to the WG list (the destination of the 'Reply-To:' field above). Unless some material corrections are posted either to the list or privately to either Co-Chair before 12:00 UTC (13:00 DUB, 14:00 AMS) on Wednesday, 4 July 2007, I intend to declare this draft "Agreed" shortly afterwards. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group

2 3

ENUM-AP-53.1: RIPE NCC to examine and report on "strange queries"
by Brett Carr 29 Jun '07

29 Jun '07

At RIPE 54 in Tallinn we commited to providing more detail on the queries prepended with a + in statistics generated last year: In the time period measured (April-November 2006) There were 13797 queries prepended with a + 10081 came from a single source. 2738 came from two further sources. The rest came from 100 different sources. We hope that this level of data satisfies this action point. Regards Brett -- Brett Carr Manager -- DNS Services Group RIPE Network Coordination Centre Amsterdam

3 3

Fwd: AEDG Meeting 6 June 07 draft minutes available on web [SEC=UNCLASSIFIED]
by Niall O'Reilly 21 Jun '07

21 Jun '07

This may be of interest to ENUM-WG participants. Thanks, Ronan! Begin forwarded message: > From: "Lupton, Ronan" <ronan.lupton(a)IE.VERIZONBUSINESS.COM> > Date: 21 June 2007 11:29:11 IST > To: ENUM-353-PAB(a)LISTSERV.HEANET.IE > Subject: FW: AEDG Meeting 6 June 07 draft minutes available on web > [SEC=UNCLASSIFIED] > Reply-To: Irish ENUM Policy Advisory Board <ENUM-353- > PAB(a)LISTSERV.HEANET.IE> > Message-Id: <CA3896DB5903C14EAAC9D8E91D1167CB0377C2DF@ms-lon- > exmb06.emea.dsmain.com> > > If anyone is interested in looking at the Australian progress > please see below. > > From: David Gill [mailto:David.Gill@acma.gov.au] > Sent: 21 June 2007 03:30 > To: ENUM > Subject: AEDG Meeting 6 June 07 draft minutes available on web > [SEC=UNCLASSIFIED] > > Discussion Group Members, > > The draft minutes of the June 6 meeting have been made available at: > http://www.acma.gov.au/WEB/STANDARD//pc=PC_2324 > > Please forward any comments or enquiries to enum(a)acma.gov.au. > > > Regards, > > David Gill > Communications Engineering Section > Australian Communication and Media Authority > 03 9963 6871 > > > > Verizon Ireland Limited – registered in Ireland – registered number > 224334 – registered office at Erne Street, Dublin 2, Ireland – VAT > number 8224334A

1 0

Fwd: ENUM Progress Matrix
by Niall O'Reilly 21 Jun '07

21 Jun '07

Let's use the mailing list, rather than just keep this among a few people. Begin forwarded message: > From: Carsten Schiefner <enumvoipsip.cs(a)schiefner.de> > Date: 20 June 2007 23:14:08 IST > To: Nieminen Klaus <Klaus.Nieminen(a)ficora.fi> > Cc: Kim Davies <kim(a)cynosure.com.au>, Niall O'Reilly > <Niall.oReilly(a)ucd.ie> > Subject: Re: ENUM Progress Matrix > Message-Id: <4679A6B0.70306(a)schiefner.de> > > Dear Klaus, > > Nieminen Klaus wrote: >> We considered the need to answer the questions and the result of the >> internal discussions was that we would like to keep the information >> part as short as possible as longer text seem to make finding out the >> relevant information harder. I must also say that some of the >> questions >> are rather irrelevant for commercial implementations. > > please feel invited to suggest a better wording where appropriate. > Of course, we are open to any improvement this data collection can > get. > > Thanks in advance - best regards, > > Carsten /Niall

1 0

Thorsten Toenges/EMD/Merck ist außer Haus.
by Thorsten.Toenges＠merck.de 19 Jun '07

19 Jun '07

I will be out of the office starting 15.06.2007 and will not return until 20.06.2007. Ich werde Ihre Nachricht nach meiner Rückkehr beantworten. Bei technischen Fragen wenden Sie sich bitte an den User Support unter 7777 This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck does not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck does not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith.

1 0

Re: ENUM in the blogosphere
by Niall O'Reilly 08 Jun '07

08 Jun '07

On 6 Jun 2007, at 13:27, Miguel Ponce de Leon wrote: > Ireland we are giving the end users a chance to see if there is > innovation to be gained from using/deploying ENUM (As in home > subscribers can register unlike the situation in Finland). I'm not sure that it's quite as difficult as you suggest in Finland. Formally (IIUC), the situation is the same: the Tier-1 registry (FICORA, IENUM) only deals with Tier-2 registrars/service-providers. As a startup initiative, IENUM is offering an interim Tier-2 registrar-of-last-resort service. It may be that there is a sufficient number of approachable Tier-2 service providers in Finland for this not to be needed over there. I don't know. Certainly, the FICORA web site seems to avoid giving any helpful hint. Maybe Klaus would like to comment? /Niall

3 2

Belarus ENUM delegation
by Vat 01 Jun '07

01 Jun '07

Hello! I am interested in presentation of my country, Belarus, in the list of approved ENUM delegations. The state structures do not wish to develop services similar ENUM, therefore I would like to advance itself the given service for people to improve their life,and also I want, that Belarus was the developed state in sphere of information technologies. And I have some questions how to delegee country code +375. Whether it is possible to take delegation on The individual businessman or it is necessary to register ENUM on Limited Company? Payment how many will manage, payment in month, year how many will manage? Whether the coordination with the Ministry of Communications is necessary on that that they not against to entitle to delegation? How long will be process of delegation in case of the positive answer? Whether that any coordination is necessary with whom? Best regards, Dmitry Gurbo --- Собрались в отпуск? Поиск туров - ТУТ: http://tourism.tut.by

1 0

RE: [enum-wg] ENUM status page at enumdata.org
by Antoin Verschuren 24 May '07

24 May '07

1. What is the country and E.164 code? The Netherlands, +31 2. Who is the delegate for the E.164 code? Stichting Enum Nederland Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands 3. The status of deployment (notdelegated>applied>delegated/objected>trial>hiatus>production) delegated 4. ENUM Project contact details (telephone, email, web) Tier-1 registry: Stichting Enum Nederland Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands Phone: +31 26 3525576 Fax: +31 26 3525577 Web: http://www.enum.nl Email: info(a)enum.nl Public ENUM platform: Starting June 18 2007: Web: http://www.enuminnederland.nl The public platform will discuss and advice the registry about policy. 5. Is a trial being, or going to be, conducted? No 1. What type of numbers are being used in the trial? None 6. Is there work or plans toward full permanent deployment? Yes, end of 2007 1. What type of numbers are to be used in full deployment? Will be advised by the Public ENUM platform. 7. Who is leading the ENUM project? (government, industry working group, etc.) The tier-1 registry is Stichting Enum Nederland The public ENUM platform will be industry working groups, led by ecp.nl and isoc.nl 8. Who operates the ccTLD for that country at present? SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands 9. What type of organisation runs the ccTLD? (state, private, academic, etc.) Not-for-profit 10. What is the ccTLD legal regulation, if any? None 11. Who is the current Tier 1 registry? Stichting Enum Nederland 12. Who is, or will be, the permanent Tier 1 registry? Stichting Enum Nederland 13. How will the Tier 1 registry selection be made? (i.e. decision, license, concession, agreement, public procurement, etc.) Has been done. Agreement with governament after market consultation. 14. How will the method of cost recovery for the Tier 1 registry's operations? TBD 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? Will be advised by the Public ENUM platform. 18. Is there/will there be a special number block for ENUM and/or IP Telephony? Yes, there are 2 numberblocks (+3185 and +3191) for VoIP services. 19. Is there special treatment for unlisted numbers? No, see also 21. 20. Are there any plans for infrastructure ENUM? TBD 21. What is your ENUM WHOIS address? ENUM does not need whois. 22. Please provide the history of ENUM trials, projects etc., if any. 2001-2002 NLEG report (see www.enuminnederland.nl) 2002 Delegation of 1.3.e164.arpa to governament (Ministry Economic Affairs) 2002-2005 No interest from market 2005 VoIP boom, sudden interest 2006 SIDN starts ENUM initiative, founds Stichting ENUM Nederland (ENUM NL) 2006 Market consultation 31-09-2006 Redelegation of 1.3.e164.arpa to Stichting ENUM Nederland 22-03-2007 Governament and ENUM NL sign agreement on terms for tier-1 registry 18-06-2007 ECP and ISOC NL launch Public ENUM platform 23. What are your future plans? (and dates if available) Operational end 2007 24. What is your date estimate on a production ENUM registry launch? See 23. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

1 0

Re: Status info for enumdata.org
by Volker Messemer/Denic 23 May '07

23 May '07

Dear colleagues, here is the update from Germany for the information shown on http://enumdata.org/: 1. What is the country and E.164 code? Germany, +49 2. Who is the delegate for the E.164 code? DENIC eG Wiesenhüttenplatz 26 60329 Frankfurt Germany 3. The status of deployment (notdelegated>applied>delegated/objected>trial>hiatus>production) production 4. ENUM Project contact details (telephone, email, web) DENIC eG Wiesenhüttenplatz 26 60329 Frankfurt Germany Tel: +49 69 27235 0 Email: enum(a)denic.de Web: http://www.denic.de/en/enum 5. Is a trial being, or going to be, conducted? A Trial was conducted from September 2002 to January 2006 6. What type of numbers are being used in the trial? - geographical numbers - mobile numbers - free-phone numbers - personal numbers - national numbers - service numbers 7. Is there work or plans toward full permanent deployment? Full permanent deployment has been launched in January 2006. 8. What type of numbers are to be used in full deployment? In the full deployment, the same number ranges are used as in the trial: - geographical numbers - mobile numbers - free-phone numbers - personal numbers - national numbers - service numbers 9. Who is leading the ENUM project? (government, industry working group, etc.) Industry (DENIC eG) 10. Who operates the ccTLD for that country at present? DENIC eG Wiesenhüttenplatz 26 60329 Frankfurt Germany 11. What type of organisation runs the ccTLD? (state, private, academic, etc.) private 12. What is the ccTLD legal regulation, if any? None 13. Who is the current Tier 1 registry? DENIC eG Wiesenhüttenplatz 26 60329 Frankfurt Germany 14. Who is, or will be, the permanent Tier 1 registry? DENIC eG Wiesenhüttenplatz 26 60329 Frankfurt Germany 15. How will the Tier 1 registry selection be made? (i.e. decision, license, concession, agreement, public procurement, etc.) Initiative of the industry concerned 16. How will the method of cost recovery for the Tier 1 registry's operations? Charging of Domains 17. Will there be more than one Tier 1 provider for the country? No 18. Will there be ENUM registrars? Yes 19. What will be the ENUM validation technique? Various techniques were developed by the registrars during the trial phase and are used now in the production phase. 20. Is there/will there be a special number block for ENUM and/or IP Telephony? The number block for national numbers (+49 32) was intended for VoIP telephony but it is not widely used. 21. Is there special treatment for unlisted numbers? No 22. Are there any plans for infrastructure ENUM? The discussion on infrastructure ENUM has started in Q4 2006. 23. What is your ENUM WHOIS address? http://www.denic.de/en/enum-whois/index.jsp 24. Please provide the history of ENUM trials, projects etc., if any. See http://www.denic.de/en/enum/index.html 25. What are your future plans? (and dates if available) See http://www.denic.de/en/enum/index.html Kind Regards Volker Messemer -- +---------------------------------+--------------------------------+ | Volker Messemer | Tel: +49 69 27235 421 | | DENICoperations | Fax: +49 69 27235 234 | | DENIC eG | E-Mail: messemer(a)denic.de | | Wiesenhüttenplatz 26 | http://www.denic.de | | 60329 Frankfurt am Main | | | DE | | +---------------------------------+--------------------------------+ | Sitz: Frankfurt am Main | | Eingetragen unter Nr. 770 im Genossenschaftsregister beim | | Amtsgericht Frankfurt am Main | | Vorstand: Andreas Bäß, Stephan Deutsch, Marcus Schäfer, | | Carsten Schiefner | | Vorsitzender des Aufsichtsrats: Elmar Knipp | +---------------------------------+--------------------------------+ | PGP-KeyID: 0xDCA306E4 | | Fingerprint: FD9C 7B19 816D 59D6 33FE 2665 10F5 AB5C DCA3 06E4 | +---------------------------------+--------------------------------+

1 0

ENUM status page at enumdata.org
by Carsten Schiefner 22 May '07

22 May '07

Dear ENUM colleagues, I have mentioned it under agenda item C. of the last ENUM WG session (cf. http://www.ripe.net/ripe/meetings/ripe-54/agendas/enum.html) already, but would like to repeat it here: If you represent an ENUM Tier 1 registry or have good contacts to one, please visit - or make them visiting, respectively - http://www.enumdata.org/ to check whether the data for that very registry provided is still correct - or not yet filled in at all. Please send any updates you may have to <enum-wg-chair(a)ripe.net>. Thank you for your cooperation. Best regards, Carsten Schiefner (on behalf of the ENUM WG Co-Chairs)

1 0

RE: [enum-wg] DNSMON for enum zones
by Antoin Verschuren 11 May '07

11 May '07

Jim Reid wrote: > > Wearing my Board hat, I am extremely uncomfortable with the NCC > straying from its core function (running an IP registry) by offering > non-core services that could and should be provided by others. I hope > DNSMON doesn't turn into a repeat of the current layer-9 issues with > DNS hosting at the NCC. Then you're also uncomfortable with RIPE being tier-0 ENUM registry. This keeps popping up. If RIPE offers services outside their IP registry task, it should accomodate for it. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 680 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

4 6

Radio URL
by Jim Reid 10 May '07

10 May '07

You can listen to an excellent business programme about internet/ telephony convergence at: http://www.bbc.co.uk/radio4/news/inbusiness/inbusiness_20040930.shtml This is the kind of thing that makes me proud to pay for the BBC. :-)

1 0

52.2 NCC Correspondance Archive
by Patrik Fältström 10 May '07

10 May '07

I did not see the microphone that was the closest to me, so I walked around to find one. When I found one, Carsten had already moved to the next point on the agenda :-) Mea culpa. I just want to have it said that I find the archive extremely valuable. To some degree it is more important for me to have the archive available than in any specific format. I have already tried to get information about some delegation, and have not found it... That said, I rather see one webpage per countrycode, and then one link per "document" than a zip file, archive or whatever. Given all those files exists, one could have a link to a zip file as well. But, most important, make the detailed communication available. "Just do it" Patrik

2 1

DNSMON for enum zones
by Ondřej Surý 09 May '07

09 May '07

Hi, I was trying to RIPE NCC DNSMON service for our 0.2.4.e164.arpa and it was suggested to open this issue on enum-wg, since DNSMON is available only for TLDs according to current policies. I think it would be good idea to change that policy to include ENUM zones as well. Ondrej. -- Ondřej Surý technický ředitel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americká 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 -----------------------------------------

4 6

Delegation of +62/2.6.e164.arpa completed
by Carsten Schiefner 07 May '07

07 May '07

Dear colleagues, "There still is a mistake in your email"... This time is has successfully hidden in the subject - my apologies. It is Indonesia/+62/2.6.e164.arpa, not Vietnam/+84/4.8.e164.arpa. Best regards, Carsten Schiefner -------- Original Message -------- Subject: [enum-wg] Delegation of +84/4.8.e164.arpa completed Date: Mon, 07 May 2007 13:07:17 +0300 From: Carsten Schiefner <enumvoipsip.cs(a)schiefner.de> To: enum-wg(a)ripe.net Dear colleagues, the ENUM delegation request for 2.6.e164.arpa - +62 is Indonesia's E.164 CC - was confirmed by ITU-T TSB on 26 Mar 2007. As per 2 May 2007, 2.6.e164.arpa is delegated to ns1.cbn.net.id. [202.158.20.1, 2001:D10:2:53::53] ns2.cbn.net.id. [202.158.40.1, 2001:D10:A:53::53] ns.enum.postel.go.id. [203.119.54.6] ns1.indosat.net.id. [202.155.0.20] 2.6.e164.arpa becomes the 43rd ENUM delegation. Welcome, Indonesia! :-) Best, Carsten Schiefner (RIPE ENUM WG Co-Chair)

1 0

Delegation of +84/4.8.e164.arpa completed
by Carsten Schiefner 07 May '07

07 May '07

Dear colleagues, the ENUM delegation request for 2.6.e164.arpa - +62 is Indonesia's E.164 CC - was confirmed by ITU-T TSB on 26 Mar 2007. As per 2 May 2007, 2.6.e164.arpa is delegated to ns1.cbn.net.id. [202.158.20.1, 2001:D10:2:53::53] ns2.cbn.net.id. [202.158.40.1, 2001:D10:A:53::53] ns.enum.postel.go.id. [203.119.54.6] ns1.indosat.net.id. [202.155.0.20] 2.6.e164.arpa becomes the 43rd ENUM delegation. Welcome, Indonesia! :-) Best, Carsten Schiefner (RIPE ENUM WG Co-Chair)

1 0

RIPE 53 draft minutes - Last reminder!
by Carsten Schiefner 02 May '07

02 May '07

Dear colleagues - the still first draft is available at: http://www.ripe.net/ripe/wg/enum/minutes/r53-minutes.html For your convenience you can also find it below as plain TXT. Please send in any comments and/or corrections you may have to this list directly and/or to <enum-wg-chair(a)ripe.net>. Please note that we have set the deadline for such contributions by email to Wednesday, 9 May 2007, 12:00 UTC/15:00 Tallinn local time. Further objections will be acceped in person at the WG session, with immediate decision on dealing with them at the meeting; they could need more time on list. In the absence of any objections, the minutes will be declared "final" as a direct result of the completion of this agenda item. Best, Carsten (on behalf of the ENUM WG Co-Chairs) = - = - = Draft ENUM Working Group Minutes from RIPE 53 RIPE Meeting: 53 Working Group: ENUM Status: Draft Revision Number: 1 * content to enum-wg-chair(a)ripe.net * format to webmaster(a)ripe.net RIPE 53 - Hotel Krasnapolsky - St. Johns II - 2006-10-04 - 14:00-15:30 Meeting Chair: Niall O'Reilly (UCD - University College Dublin) Scribe: Alex Le Heux (RIPE NCC) Jabber: Catherine Carr (RIPE NCC) Webcast and Feedback Archives: http://www.ripe.net/ripe/meetings/ripe-53/sessions-archive.html Start: 14:00 Administrative matters The Chair welcomes everyone, the scribe and the jabberwock. There are no additional agenda points to add to the agenda although the order will be different: http://www.ripe.net/ripe/meetings/ripe-53/agendas/enum.html There were no comments on the minutes from the RIPE52 meeting, so the minutes are approved. Review of RIPE52 action items: 52.2 - Carsten Schiefner (Deutsche Telekom) There has been some discussion with the RIPE NCC. A .zip file has the advantages of making it easy to add more files and it is a single download. Separate files give a good overview, can be well structured and are the same as the old concept. A downside is that it will produce many hits while searching. Carsten Schiefner will once more put this matter to the WG Mailing List. [ ENUM-AP-52.2 remains open ] The other action items will be dealt with in other agenda items. Presentation: Operations Update - Brett Carr (RIPE NCC) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-bc-upd.pdf Questions: Patrick Faltstrom (Cisco): Are you doing lameness checks on DNS servers? Brett Carr (RIPE NCC): Not yet. Patrick Faltstrom (Cisco): Will the RIPE NCC take the initiative for that? Brett Carr (RIPE NCC): Yes. Peter Koch (DENIC): You had a slide about strange queries, starting with a plus. Have you considered they could be a misimplementation of the DDDS algorithm? Have you looked into from how many different sources these queries originated? Brett Carr (RIPE NCC): No, but I have all the stats. But we can. => Action item on the RIPE NCC [ ENUM-AP-53.1: RIPE NCC to examine and report on "strange queries" ] Carsten Schiefner (Deutsche Telekom): The NCC is able to get stats from all servers. Will there be a further effort to break them down by country code? Brett Carr (RIPE NCC): We tried, but not all providers have the resources to run the stats on their machines and some are very wary from a privacy point of view. Otmar Lendl (NIC.AT, via Jabber): Please get the DNS performance of the Chinese server up to speed (or provide glue for them). Resolving e164-arpa.cnnic.net.cn is quite broken. Brett Carr (RIPE NCC): Chinese are working on moving their service to a different server. We are already in contact with them. Presentation: Quality Task Force - Carsten Schiefner (Deutsche Telekom) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-cs-qtf.pdf Niall O'Reilly (University College Dublin): Will you follow up on the Quality Task Force and follow up on the lameness checks by the NCC as an action item? Carsten Schiefner (Deutsche Telekom): Yes. [ ENUM-AP-53.2: Carsten Schiefner to follow up on Quality TF ] Andrei Robachevsky (RIPE NCC): Why do you think it's impossible to tell an ENUM Tier-1 registry to be compliant? Jim Reid (RIPE NCC Exec Board): The answer to that is not technical, it's political. It's run by the country according to that country's rules. So it's a matter of national sovereignty, so I don't think it's the business of the NCC or anybody else to tell them how to run their name servers. Andrei Robachevsky (RIPE NCC): Can this issue be brought into the technical plane rather than the political plane? I understand that delegation to a particular entity is a political issue, but running DNS servers is probably more technical. Jim Reid (RIPE NCC Exec Board): It is a technical issue, but from a government perspective, they feel entitled to do it they way they want to. Patrik Faltstrom (Cisco): That's why I asked who took the initiative for doing the checks. There is a very, very big difference between whether a country asks the RIPE NCC directly or indirectly to do these lameness checks and notify them when something is broken and having someone tell a country that they're doing the wrong thing. Carsten Schiefner (Deutsche Telekom): The original initiative by the RIPE NCC for the lameness checks was for the reverse mapping space only. Jim Reid (RIPE NCC Exec Board): It's not an issue of DNS, it's an issue of phone numbers and telephone numbers being an item of national sovereignty. Daniel Karrenberg (RIPE NCC): I fully agree with Patrik and what Carsten said. What you want to see is a best common practice written up. That's not telling a country on how they should run their DNS. Being from the NCC I am slightly uncomfortable with the hands off approach that is suggested by Patrik and Jim. In any other constellation I can think of; the parent registry has some rules actually. I'm uneasy about this because the RIPE NCC runs at Tier-0 and any really bad quality falls back on the RIPE NCC. We were getting flak for things not working, so I think the NCC is entitled to make strong suggestions. Niall O'Reilly (University College Dublin): (taking chair hat off) There is a delicate balancing act here. If there isn't a safety net that's a bad thing, if the safety net interferes with national sovereignty, that is a bad thing too. Jim Reid (RIPE NCC Exec Board): I agree with what Daniel says. The RIPE NCC must be careful though with it's role as Tier-0 registry. The instructions to the NCC didn't mention lame delegation checking. If the NCC is perceived to exceed its authority, there could be trouble. Olaf Kolkman (NLnet Labs): About the BCP that Daniel mentioned, I think it's more important to provide a set of minimum requirements. Not "this is the bar you should reach" but "this is the bar you should step over" to at least be good. Field Reports Presentation - Ondrej Filip (NIC.CZ) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-of-czr.pdf Carsten Schiefner (Deutsche Telekom): I would be surprised if a premium rate number holder would actually register it. Ondrej Filip (NIC.CZ): It's an option. Carsten Schiefner (Deutsche Telekom): If you go commercial in 2007, will you clean the trial database? Ondrej Filip (NIC.CZ): No, we will continue on the same platform. Jim Reid (RIPE NCC Exec Board): What are your plans to incorporate this WG's thoughts on DNS quality and incorporate monitoring into the platform? Ondrej Filip (NIC.CZ): No plans. Sungwoo Shin (KRNIC): You will use trial user data when you move to the commercial phase. Will there be any validation of that data? Ondrej Filip (NIC.CZ): Yes, the trial phase is the same as commercial, except without payment. So there is normal validation. Sungwoo Shin (KRNIC): The trial users can use it freely and make a free call without charge? Ondrej Filip (NIC.CZ): Yes, you can use it to make a free call. Presentation - Jim Reid (UKEG) http://www.ripe.net/ripe/meetings/ripe-53/presentations/ukeg.pdf Carsten Schiefner (Deutsche Telekom): Is external DNS monitoring part of the RFP? Jim Reid (UKEG): Yes. Otmar Lendl (NIC.AT, via Jabber): Are the SIP URIs in the CRUE records supposed to point to open SIP server, and thus reachable by any caller on the Internet? Jim Reid (UKEG): The SIP server address can point to wherever the carrier chooses, we don't care. Bernie Hoeneisen (SWITCH, via Jabber): In case a user overrides his ENUM entry as populated by the carrier: what will appear in the zone file you are directly providing/selling to the carriers? User provided NS RRs or original carrier populated NAPTR RRs? Jim Reid (UKEG): There will be two NAPTR records, if there is a delegation request, they will be replaced with NS records. Presentation - Sungwoo Shin (KRNIC) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-ss-kor.pdf Niall O'Reilly (University College Dublin): Will monitoring be built into the requirements for the service? Sungwoo Shin (KRNIC): I don't disagree with Jim's idea. Presentation - Antoin Verschuren (SIDN) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-av-nl.pdf Antoin Verschuren (SIDN): To answer Jim's question: Yes, we will be happy to do so! Jim Reid (RIPE NCC Exec Board): This is about the consultation you are doing. There are two things: One for redelegation and two, a future meeting where people can comment on the general plan. Is that only for Dutch people? Antoin Verschuren (SIDN): It's an open platform. Presentation - Robert Schischka (NIC.AT): http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-rs-aus.pdf Wolfgang Tremmel (DE-CIX): Is it possible that different carriers querying get different views? Robert Schischka (NIC.AT): No, it's a single public tree. Some carriers might have a different view internally, but not from the outside. Jim Reid (RIPE NCC Exec Board): Are you using wildcards? Robert Schischka (NIC.AT): Yes, we have to, we have an open numbering plan. Olaf Kolkman (NLnet Labs): From a DNS client perspective, if I were to query the tree would I need to know the country number plan? Robert Schischka (NIC.AT): Yes, you need to know where the 'i' is so you need to know how long the country code is. It's a dirty solution but the only way to go now. Olaf Kolkman (NLnet Labs): There may be other alternatives. Robert Schischka (NIC.AT): Everybody agrees that in the end it needs to be a separate tree. There was a lengthy discussion in the IETF, the "Dallas treaty" was an interim solution, and will be easy to change. Peter Koch (DENIC): This kind of infrastructure stuff is kind of broken. For years we have been hearing that it would take years to convince the ITU. Has there been any effort so far to actually talk to the ITU and start this? Robert Schischka (NIC.AT): I don't think the issue has been going on for years, but I don't think anyone is talking to the ITU about this very much. Maybe we should see several countries interested in this, to give more power to the discussion. The tech community wants a neat solution, but the key is buy-in from the telcos, not how the tree is named. Peter Koch (DENIC): One of the problems is that the specification is a bit brittle. Robert Schischka (NIC.AT): No one in carrier land really cares about this. Presentation: ENUM Next Generation - Patrik Faltstrom (Cisco) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-pf-nge.pdf Antoin Verschuren (SIDN): How are you going to split authority if you do a delegation on for example a path for a number block: if you want to redelegate, for open number plans for instance? Patrik Faltstrom (Cisco): There are two possibilities: 1. A neutral party similar to the portability database administrator operates a database. 2. Do delegations higher up in the tree, but those parties must be neutral as well. There is no portability in DNS. Daniel Karrenberg (RIPE NCC): How are applications supposed to make use of this? Patrik Faltstrom (Cisco): Two ways: 1. Look up the NAPTR records for the phone numbers. 2. If you understand SIP, you can look up _sip._e2u.[phone number] and use that. Daniel Karrenberg (RIPE NCC): And the _h323 and _message labels are found in some lists? Patrik Faltstrom (Cisco): In the existing ENUM specification there is a IANA registry for those labels, including a registration mechanism. Issues for other working groups: Niall O'Reilly will alert the DB WG and the NCC SERVICES WG as action item 53.3 that we expect to have consensus soon on the NON-REGISTRY issue. [ ENUM-AP-53.3: Niall O'Reilly to alert other WGs re NON-REGISTRY ] AOB The graphic of the T-Shirt will be on Rosie. Meeting Ends 15:55

1 0

Draft agenda RIPE 54 ENUM WG
by Niall O'Reilly 23 Apr '07

23 Apr '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is the draft agenda for the ENUM WG session at RIPE 54. A. (0) 10' Administrivia [Session chair] Welcome, microphone etiquette Scribe, Jabberwok, ... Agenda bashing Minutes 53 B. (10) 15' Action points C. (25) 20' Short News Status Page UK Update [JR] RFC-watch D. (45) 20' IETF update [PAF] E. (65) 20' Contrarian view of ENUM [GIH] X. Intercommunication with other WG's Y. AOB Z. (85) 5' Close [Session chair] Summarize (new, ongoing) AP's Look forward to 55/AMS Announce coffee .. (90) Coffee On behalf of the co-chairs, Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFGLN+jeYfkja6ZXtkRAsKLAJwMG2Fxb6zDjzpcbw9NUxy+36mRmACcCiia 5kouXs5jRP55q185bYdSMUI= =EBF6 -----END PGP SIGNATURE-----

1 0

RIPE 53 draft minutes - Reminder!
by Carsten Schiefner 11 Apr '07

11 Apr '07

Dear colleagues - the still first draft is available at: http://www.ripe.net/ripe/wg/enum/minutes/r53-minutes.html For your convenience you can also find it below as plain TXT. Please send in any comments and/or corrections you may have to this list directly and/or to <enum-wg-chair(a)ripe.net>. Please note that we have set the deadline for such contributions by email to Wednesday, 9 May 2007, 12:00 UTC/15:00 Tallinn local time. Further objections will be acceped in person at the WG session, with immediate decision on dealing with them at the meeting; they could need more time on list. In the absence of any objections, the minutes will be declared "final" as a direct result of the completion of this agenda item. Best, Carsten (on behalf of the ENUM WG Co-Chairs) = - = - = Draft ENUM Working Group Minutes from RIPE 53 RIPE Meeting: 53 Working Group: ENUM Status: Draft Revision Number: 1 * content to enum-wg-chair(a)ripe.net * format to webmaster(a)ripe.net RIPE 53 - Hotel Krasnapolsky - St. Johns II - 2006-10-04 - 14:00-15:30 Meeting Chair: Niall O'Reilly (UCD - University College Dublin) Scribe: Alex Le Heux (RIPE NCC) Jabber: Catherine Carr (RIPE NCC) Webcast and Feedback Archives: http://www.ripe.net/ripe/meetings/ripe-53/sessions-archive.html Start: 14:00 Administrative matters The Chair welcomes everyone, the scribe and the jabberwock. There are no additional agenda points to add to the agenda although the order will be different: http://www.ripe.net/ripe/meetings/ripe-53/agendas/enum.html There were no comments on the minutes from the RIPE52 meeting, so the minutes are approved. Review of RIPE52 action items: 52.2 - Carsten Schiefner (Deutsche Telekom) There has been some discussion with the RIPE NCC. A .zip file has the advantages of making it easy to add more files and it is a single download. Separate files give a good overview, can be well structured and are the same as the old concept. A downside is that it will produce many hits while searching. Carsten Schiefner will once more put this matter to the WG Mailing List. [ ENUM-AP-52.2 remains open ] The other action items will be dealt with in other agenda items. Presentation: Operations Update - Brett Carr (RIPE NCC) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-bc-upd.pdf Questions: Patrick Faltstrom (Cisco): Are you doing lameness checks on DNS servers? Brett Carr (RIPE NCC): Not yet. Patrick Faltstrom (Cisco): Will the RIPE NCC take the initiative for that? Brett Carr (RIPE NCC): Yes. Peter Koch (DENIC): You had a slide about strange queries, starting with a plus. Have you considered they could be a misimplementation of the DDDS algorithm? Have you looked into from how many different sources these queries originated? Brett Carr (RIPE NCC): No, but I have all the stats. But we can. => Action item on the RIPE NCC [ ENUM-AP-53.1: RIPE NCC to examine and report on "strange queries" ] Carsten Schiefner (Deutsche Telekom): The NCC is able to get stats from all servers. Will there be a further effort to break them down by country code? Brett Carr (RIPE NCC): We tried, but not all providers have the resources to run the stats on their machines and some are very wary from a privacy point of view. Otmar Lendl (NIC.AT, via Jabber): Please get the DNS performance of the Chinese server up to speed (or provide glue for them). Resolving e164-arpa.cnnic.net.cn is quite broken. Brett Carr (RIPE NCC): Chinese are working on moving their service to a different server. We are already in contact with them. Presentation: Quality Task Force - Carsten Schiefner (Deutsche Telekom) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-cs-qtf.pdf Niall O'Reilly (University College Dublin): Will you follow up on the Quality Task Force and follow up on the lameness checks by the NCC as an action item? Carsten Schiefner (Deutsche Telekom): Yes. [ ENUM-AP-53.2: Carsten Schiefner to follow up on Quality TF ] Andrei Robachevsky (RIPE NCC): Why do you think it's impossible to tell an ENUM Tier-1 registry to be compliant? Jim Reid (RIPE NCC Exec Board): The answer to that is not technical, it's political. It's run by the country according to that country's rules. So it's a matter of national sovereignty, so I don't think it's the business of the NCC or anybody else to tell them how to run their name servers. Andrei Robachevsky (RIPE NCC): Can this issue be brought into the technical plane rather than the political plane? I understand that delegation to a particular entity is a political issue, but running DNS servers is probably more technical. Jim Reid (RIPE NCC Exec Board): It is a technical issue, but from a government perspective, they feel entitled to do it they way they want to. Patrik Faltstrom (Cisco): That's why I asked who took the initiative for doing the checks. There is a very, very big difference between whether a country asks the RIPE NCC directly or indirectly to do these lameness checks and notify them when something is broken and having someone tell a country that they're doing the wrong thing. Carsten Schiefner (Deutsche Telekom): The original initiative by the RIPE NCC for the lameness checks was for the reverse mapping space only. Jim Reid (RIPE NCC Exec Board): It's not an issue of DNS, it's an issue of phone numbers and telephone numbers being an item of national sovereignty. Daniel Karrenberg (RIPE NCC): I fully agree with Patrik and what Carsten said. What you want to see is a best common practice written up. That's not telling a country on how they should run their DNS. Being from the NCC I am slightly uncomfortable with the hands off approach that is suggested by Patrik and Jim. In any other constellation I can think of; the parent registry has some rules actually. I'm uneasy about this because the RIPE NCC runs at Tier-0 and any really bad quality falls back on the RIPE NCC. We were getting flak for things not working, so I think the NCC is entitled to make strong suggestions. Niall O'Reilly (University College Dublin): (taking chair hat off) There is a delicate balancing act here. If there isn't a safety net that's a bad thing, if the safety net interferes with national sovereignty, that is a bad thing too. Jim Reid (RIPE NCC Exec Board): I agree with what Daniel says. The RIPE NCC must be careful though with it's role as Tier-0 registry. The instructions to the NCC didn't mention lame delegation checking. If the NCC is perceived to exceed its authority, there could be trouble. Olaf Kolkman (NLnet Labs): About the BCP that Daniel mentioned, I think it's more important to provide a set of minimum requirements. Not "this is the bar you should reach" but "this is the bar you should step over" to at least be good. Field Reports Presentation - Ondrej Filip (NIC.CZ) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-of-czr.pdf Carsten Schiefner (Deutsche Telekom): I would be surprised if a premium rate number holder would actually register it. Ondrej Filip (NIC.CZ): It's an option. Carsten Schiefner (Deutsche Telekom): If you go commercial in 2007, will you clean the trial database? Ondrej Filip (NIC.CZ): No, we will continue on the same platform. Jim Reid (RIPE NCC Exec Board): What are your plans to incorporate this WG's thoughts on DNS quality and incorporate monitoring into the platform? Ondrej Filip (NIC.CZ): No plans. Sungwoo Shin (KRNIC): You will use trial user data when you move to the commercial phase. Will there be any validation of that data? Ondrej Filip (NIC.CZ): Yes, the trial phase is the same as commercial, except without payment. So there is normal validation. Sungwoo Shin (KRNIC): The trial users can use it freely and make a free call without charge? Ondrej Filip (NIC.CZ): Yes, you can use it to make a free call. Presentation - Jim Reid (UKEG) http://www.ripe.net/ripe/meetings/ripe-53/presentations/ukeg.pdf Carsten Schiefner (Deutsche Telekom): Is external DNS monitoring part of the RFP? Jim Reid (UKEG): Yes. Otmar Lendl (NIC.AT, via Jabber): Are the SIP URIs in the CRUE records supposed to point to open SIP server, and thus reachable by any caller on the Internet? Jim Reid (UKEG): The SIP server address can point to wherever the carrier chooses, we don't care. Bernie Hoeneisen (SWITCH, via Jabber): In case a user overrides his ENUM entry as populated by the carrier: what will appear in the zone file you are directly providing/selling to the carriers? User provided NS RRs or original carrier populated NAPTR RRs? Jim Reid (UKEG): There will be two NAPTR records, if there is a delegation request, they will be replaced with NS records. Presentation - Sungwoo Shin (KRNIC) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-ss-kor.pdf Niall O'Reilly (University College Dublin): Will monitoring be built into the requirements for the service? Sungwoo Shin (KRNIC): I don't disagree with Jim's idea. Presentation - Antoin Verschuren (SIDN) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-av-nl.pdf Antoin Verschuren (SIDN): To answer Jim's question: Yes, we will be happy to do so! Jim Reid (RIPE NCC Exec Board): This is about the consultation you are doing. There are two things: One for redelegation and two, a future meeting where people can comment on the general plan. Is that only for Dutch people? Antoin Verschuren (SIDN): It's an open platform. Presentation - Robert Schischka (NIC.AT): http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-rs-aus.pdf Wolfgang Tremmel (DE-CIX): Is it possible that different carriers querying get different views? Robert Schischka (NIC.AT): No, it's a single public tree. Some carriers might have a different view internally, but not from the outside. Jim Reid (RIPE NCC Exec Board): Are you using wildcards? Robert Schischka (NIC.AT): Yes, we have to, we have an open numbering plan. Olaf Kolkman (NLnet Labs): From a DNS client perspective, if I were to query the tree would I need to know the country number plan? Robert Schischka (NIC.AT): Yes, you need to know where the 'i' is so you need to know how long the country code is. It's a dirty solution but the only way to go now. Olaf Kolkman (NLnet Labs): There may be other alternatives. Robert Schischka (NIC.AT): Everybody agrees that in the end it needs to be a separate tree. There was a lengthy discussion in the IETF, the "Dallas treaty" was an interim solution, and will be easy to change. Peter Koch (DENIC): This kind of infrastructure stuff is kind of broken. For years we have been hearing that it would take years to convince the ITU. Has there been any effort so far to actually talk to the ITU and start this? Robert Schischka (NIC.AT): I don't think the issue has been going on for years, but I don't think anyone is talking to the ITU about this very much. Maybe we should see several countries interested in this, to give more power to the discussion. The tech community wants a neat solution, but the key is buy-in from the telcos, not how the tree is named. Peter Koch (DENIC): One of the problems is that the specification is a bit brittle. Robert Schischka (NIC.AT): No one in carrier land really cares about this. Presentation: ENUM Next Generation - Patrik Faltstrom (Cisco) http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-pf-nge.pdf Antoin Verschuren (SIDN): How are you going to split authority if you do a delegation on for example a path for a number block: if you want to redelegate, for open number plans for instance? Patrik Faltstrom (Cisco): There are two possibilities: 1. A neutral party similar to the portability database administrator operates a database. 2. Do delegations higher up in the tree, but those parties must be neutral as well. There is no portability in DNS. Daniel Karrenberg (RIPE NCC): How are applications supposed to make use of this? Patrik Faltstrom (Cisco): Two ways: 1. Look up the NAPTR records for the phone numbers. 2. If you understand SIP, you can look up _sip._e2u.[phone number] and use that. Daniel Karrenberg (RIPE NCC): And the _h323 and _message labels are found in some lists? Patrik Faltstrom (Cisco): In the existing ENUM specification there is a IANA registry for those labels, including a registration mechanism. Issues for other working groups: Niall O'Reilly will alert the DB WG and the NCC SERVICES WG as action item 53.3 that we expect to have consensus soon on the NON-REGISTRY issue. [ ENUM-AP-53.3: Niall O'Reilly to alert other WGs re NON-REGISTRY ] AOB The graphic of the T-Shirt will be on Rosie. Meeting Ends 15:55

1 0

Agenda call for ENUM WG at RIPE 54, Tallinn, 7-11 May 2007
by Niall O'Reilly 31 Mar '07

31 Mar '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 RIPE 54 is just 5 weeks away: probably much closer than most of us realize. Please let Carsten or me have suggestions or proposals for the ENUM-WG Agenda soon. If you're one of the "usual suspects", and have already half-agreed (or more) to give a presentation, now would be a good time to confirm your intentions. It you're not one of those, you're more than welcome to speak up now too! I'm looking forward to a useful and interesting meeting in Tallinn, and hope to see as many of you all there as possible. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFGDn+YeYfkja6ZXtkRAnRWAJ9HGTwCecNTVVucBoT1JB1Y67s1VwCeIoCf p2xypCeGJadmGs3bFqr7/E0= =QK34 -----END PGP SIGNATURE-----

1 0

Re: Status info for enumdata.org
by Bernie Hoeneisen 30 Mar '07

30 Mar '07

Hi Niall Here the answers form the Swiss ENUM trial: 1. What is the country and E.164 code? Switzerland, +41 2. Who is the delegate for the E.164 code? Tech-Contact (source: Ripe whois) role: SWITCH Network Operation Center address: SWITCH-NOC address: SWITCH, The Swiss Education and Research Network address: Limmatquai 138 address: CH-8021 Zurich phone: +41 44 268 1530 fax-no: +41 44 268 1568 Admin-Contact (source: Ripe whois) person: Olivier Girard address: OFCOM, Swiss Federal Office of Communications address: Rue Avenir 44 address: CH-2501 Bienne address: Switzerland phone: +41 32 327 55 75 phone: +41 32 327 55 11 fax-no: +41 32 327 55 49 3. The status of deployment (notdelegated>applied>delegated/objected>trial>hiatus>production) trial 4. ENUM Project contact details (telephone, email, web) tel: +41 44 268 15 15 mailto: enum-pm(a)switch.ch web: http://www.switch.ch/enum 5. Is a trial being, or going to be, conducted? The trial is ongoing 1. What type of numbers are being used in the trial? All Swiss E.164 numbers 6. Is there work or plans toward full permanent deployment? Decision making process ongoing 1. What type of numbers are to be used in full deployment? Most likely all Swiss E.164 numbers 7. Who is leading the ENUM project? (government, industry working group, etc.) SWITCH as the Tier-1 Registry (together with OFCOM, the regulator). 8. Who operates the ccTLD for that country at present? SWITCH 9. What type of organisation runs the ccTLD? (state, private, academic, etc.) Academic, The Swiss Education & Research Network 10. What is the ccTLD legal regulation, if any? Under the Swiss Telecommunications Law 11. Who is the current Tier 1 registry? SWITCH 12. Who is, or will be, the permanent Tier 1 registry? TBD 13. How will the Tier 1 registry selection be made? (i.e. decision, license, concession, agreement, public procurement, etc.) TBD 14. How will the method of cost recovery for the Tier 1 registry's operations? TBD 15. Will there be more than one Tier 1 provider for the country? Not planned 16. Will there be ENUM registrars? Most likely 17. What will be the ENUM validation technique? TBD 18. Is there/will there be a special number block for ENUM and/or IP Telephony? Currently there is no such number block 19. Is there special treatment for unlisted numbers? No 20. Are there any plans for infrastructure ENUM? Decision making process ongoing 21. What is your ENUM WHOIS address? No whois for ENUM 22. Please provide the history of ENUM trials, projects etc., if any. Feb 2002: OFCOM launches an ENUM consultation process Nov 2002: Workshop about ENUM at OFCOM Sep 2003: OFCOM grants Switch authorization to operate ENUM Trial Oct 2003: Start of ENUM Trial in the area of Research and Education Apr 2005: First commercial registrars join the ENUM Trial Sep 2005: Prolongation of the authorization for another 2 years term Nov 2006: RFC 4725 (ENUM Validation Architecture) published 23. What are your future plans? (and dates if available) ENUM Trial ends on 30. September 2007 Currently preparing for productive operations 24. What is your date estimate on a production ENUM registry launch? TDB cheers, Bernie, Switch, Project Manager ENUM --------------------------------- Bernhard Hoeneisen Switch Werdstrasse 2 Postfach CH-8021 Zürich tel:+41 44 268 15 54 (normal) tel:+41 43 268 15 54 (IP with ENUM) sip:hoeneisen@switch.ch fax:+41 44 253 98 98 email:hoeneisen@switch.ch

1 0

Re: [enum-wg] Status info for enumdata.org
by chenhui 29 Mar '07

29 Mar '07

Dear Niall O'Reilly, Thank you for your effort! Please update ENUM information of China as following, thanks. *************************************************************************** *What is the country and E.164 code?* China, 86 *Who is the delegate for the E.164 code?* Administrative contact: Mao Wei (China Internet Network Information Center) Techinical contact: Xiaodong Li (China Internet Network Information Center) Delegation is for Trial purpose. *The status of deployment (notdelegated >applied >delegated/objected >trial >hiatus >production)* Trial. *ENUM Project contact details (telephone, email, web)* http://www.enum.cn/en email contact: enum(a)cnnic.cn tel: 86-10-58813000 *Is a trial being, or going to be, conducted?* The trial is being. *What type of numbers are being used in the trial?* All the E.164 numbers under country code 86 can be used in the trial now. *Is there work or plans toward full permanent deployment?* Currently not decided. *What type of numbers are to be used in full deployment?* Not decided. *Who is leading the ENUM project? (government, industry working group, etc.)* MII(Ministry of Information Industry) and CNNIC leaded by MII. *Who operates the ccTLD for that country at present?* CNNIC is the ".cn" registry. See http://www.cnnic.cn/en/index/index.htm *What type of organisation runs the ccTLD? (state, private, academic, etc.) * Not-for-profit organization. *What is the ccTLD legal regulation, if any?* See http://www.cnnic.cn/html/Dir/2003/11/27/1522.htm *Who is the current Tier 1 registry?* CNNIC is the current Tier1 registry in the trial. *Who is, or will be, the permanent Tier 1 registry?* Not decided. *How will the Tier 1 registry selection be made? (i.e. decision, license, concession, agreement, public procurement, etc.) * Not decided. *How will the method of cost recovery for the Tier 1 registry's operations?* A recommendation will be submitted before full deployment. *Will there be more than one Tier 1 provider for the country? * The recommendation is one Tier 1 provider. *Will there be ENUM registrars?* There are two simulative ENUM registrars in the trial. See http://epp.enum.cn. *What will be the ENUM validation technique?* To be defined. *Is there/will there be a special number block for ENUM and/or IP Telephony?* Not decided. *Is there special treatment for unlisted numbers?* Not decided. *Are there any plans for infrastructure ENUM?* Yes, infrastructure ENUM is in the plan. *What is your ENUM WHOIS address?* See http://www.enum.cn/en . *Please provide the history of ENUM trials, projects etc., if any.* 2001, China Network Information Center (CNNIC) started up ENUM research. 2002, MII authorized doing ENUM application experiment and organized ENUM trial consortium, set up leader team and research group of the trial; Science and technology department, MII held the proseminar and decided to apply 6.8.e164.arpa for evolution trial of ENUM top level domain (TLD) ; CNNIC started up and ran 6.8.e164.arpa slave server; CNNIC began to run ONE of SIX ENUM root server (e164.arpa domain server). 2003, CNNIC published ENUM trial system, provided registration and tested resolution performance. 2004, CNNIC originated and joined the APEET (Asia-pacific ENUM Engineering Team). 2005, CNNIC studied ENUM commercial architecture and did experiment on ENUM new services. 2006, CNNIC updated ENUM trial system; studied authorization and authentication of ENUM application. *What are your future plans? (and dates if available)* N/A. *What is your date estimate on a production ENUM registry launch?* Not yet decided. ************************************************************************** Best regards! chenhui 2007-03-29 发件人： Niall O'Reilly 发送时间： 2007-02-06 19:47:19 收件人： enum-wg(a)ripe.net 抄送： Niall O'Reilly; Carsten Schiefner; Kim Davies 主题： [enum-wg] Status info for enumdata.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear ENUM-WGers, I'm happy to let you know that the "maintenance team" for the enumdata.org status page, kindly hosted by Kim Davies, has been strengthened. I expect that delays in applying updates will be noticeably shorter as a result. Speaking of updates, if you have some responsibility for or involvement in ENUM in your country, please check whether the corresponding information shown on http://enumdata.org/ is still current and, if not, mail in an updated set of responses to the standard questions to enum-wg(a)ripe.net. This will let other WG participants see your information immediately, and will put the information where the maintenance team can pick it up. Thanks and best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFyFgveYfkja6ZXtkRAnWIAJ4zCd1ajIOXiIXtO5yyFt+4kupv6ACeNUT7 3R89A1HESRtUKG3iwB7N/3E= =OZxG -----END PGP SIGNATURE-----

1 0

Status info for enumdata.org
by Niall O'Reilly 26 Mar '07

26 Mar '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear ENUM-WGers, I'm happy to let you know that the "maintenance team" for the enumdata.org status page, kindly hosted by Kim Davies, has been strengthened. I expect that delays in applying updates will be noticeably shorter as a result. Speaking of updates, if you have some responsibility for or involvement in ENUM in your country, please check whether the corresponding information shown on http://enumdata.org/ is still current and, if not, mail in an updated set of responses to the standard questions to enum-wg(a)ripe.net. This will let other WG participants see your information immediately, and will put the information where the maintenance team can pick it up. Thanks and best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFyFgveYfkja6ZXtkRAnWIAJ4zCd1ajIOXiIXtO5yyFt+4kupv6ACeNUT7 3R89A1HESRtUKG3iwB7N/3E= =OZxG -----END PGP SIGNATURE-----

2 2

DENIC's next ENUM day will be held on 27 February
by Carsten Schiefner 07 Mar '07

07 Mar '07

Dear colleagues, it is with pleasure that I can announce DENIC's *) eighth bi-annual ENUM day that will be held on 27 February 07 in Frankfurt. Please visit: http://www.denic.de/en/denic/news/news_45.html for any further information. Best regards, Carsten Schiefner *) DENIC is the registry for Germany's ccTLD .de and ENUM domain 9.4.e164.arpa

1 1

Thesis on Infrastructure ENUM options for the Netherlands
by Carsten Schiefner 20 Feb '07

20 Feb '07

Dear ENUM colleagues, yesterday an announcement was posted on the Dutch SIP & ENUM list <ISOC-SIPSIG(a)NIC.SURFNET.NL> about Lennart Maris' thesis "Infrastructure ENUM - implementation options for the Netherlands" that can be found at: http://isoc.nl/files/ScriptieLennartMaris.pdf I have had no opportunity so far to already digest it but nonetheless wanted to share that piece of information with you. Best regards, Carsten Schiefner

1 0

Future of VoIP conference - The Hague March 15th 2007
by Carsten Schiefner 07 Feb '07

07 Feb '07

As Michiel's mail has not yet shown up on the list - probably still held for moderation - I' like to forward it on his behalf. Best, Carsten -------- Original Message -------- Subject: Future of VoIP conference - The Hague March 15th 2007 Date: Tue, 6 Feb 2007 12:35:41 +0100 From: Michiel Leenaars <michiel(a)staff.isoc.nl> To: enum-wg(a)ripe.net CC: Carsten Schiefner <enumvoipsip.cs(a)schiefner.de> Invitation The Future of VoIP II 15 Maart 2007, Aula Koninklijke Bibliotheek The Hague/Den Haag (The Netherlands) Thomas Anglero (Nuclei Networks) * James Body (Truphone) * Michel de Boer (Twinklephone) * David Bryan (co-chair IETF P2PSIP WG, Sipeerior) * Adrian Georgescu (AG Projects) * Bert Hubert (Power DNS) * Ytsen Kooistra (YBK) * Olaf Kolkman (Internet Architecture Board) * Michiel Leenaars (Internet Society) * Dan Pascu (AG Projects) * Hendrik Rood (Stratix) * Antoin Verschuren (SIDN) The Hague/Den Haag, The Netherlands, February 6th 2007 The role of real-time communication via the internet is still increasing. Currently over tens of millions of households in the world are calling through VoIP, video telefony (both mobile and fixed) is increasingly popular and of better quality, and the increasing availability of User ENUM in the market is a clear signal that the migration towards all-IP is definitely on its way. From the user side, the vendor community and service providers expections are sky high - yet nobody knows which business models, technologies and services will be the ones to make it all the way to the end. The various market forces that are developing in this field need to position themselves on the basis of a good insight into technology and in the way users want to interact with that technology. That, in interaction with what the competition is doing will determine the business opportunities. For users (and governments) it is vital that the result is an open infrastructure where flexibility, stability, usability, security and service go hand in hand. On March 15th 2007 ISOC Netherlands organises the second edition of the Future of VoIP conference. Learn more about upcoming IETF standards around P2P SIP, ENUM, open source SIP clients, SIP on dual-mode GSM/WiFi devices, the possible role of Fiber to the home and interconnect issues between VoIP islands. Prominent (inter)nationale speakers such as Thomas Anglero (Nuclei Networks), James Body (Truphone), David Bryan (co-chair IETF P2PSIP WG, Sipeerior) and Olaf Kolkman (director NLnet Labs, member of the Internet Architecture Board) wil guide you along new insights from the different worlds behind VoIP and SIP. Join us in the discussion on the business models behind future communication patterns via internet, and determine your own strategy on the basis of a broad spectre of opinions, visions and experiences. The Future of VoIP conference is organized by ISOC.nl SIP special Interest Group on March 15th 2007. The conference will take place in the aula of the Koninklijke Bibliotheek (Prins Willem-Alexanderhof 5) in The Hague, the Netherlands. Participation in 'The Future of VoIP II costs 99 euro, ISOC members pay only 50 euro. The conference will be held in English. All information, including the whole programme and a registration form can be found both in English and in Dutch on: http://isoc.nl/activ/2007-FoV-II Kind regards, on behalf of the organisers, Michiel Leenaars, Adrian Georgescu director ISOC.nl vice-chair SIPSIG ===================================== About the speakers THOMAS F. ANGLERO, NUCLEI NETWORKS Thomas F. Anglero is the Founder and CEO of Nuclei Networks, the sole certifier of VoIP solutions for the Leeuwarden "Break the Dyke" Global Invitation. Mr. Anglero was recently a senior executive advisor with Telenor AS where he was responsible for Telenor's FMC and Web Service strategies. Prior, Mr. Anglero was also the CEO of Free World Dialup, VP of Vocaltec Communications and CEO of TrulyGlobal. JAMES BODY, TRUPHONE James Body is Director - Networks at Truphone, a UK based converged operator who provide mobile services utilizing dual mode GSM/WiFi handsets. James is responsible for all of the infrastructure between the handset SIP interface and the rest of the world. Following graduation from Queen Mary College, University of London and 20 years as a Regular Officer in the Royal Corps of Signals (UK Army), James 'retired' to focus on implementing VoIP based 'New Telephony' systems. He was responsible for SIPCall, the first UK public SIP<>PSTN system and was co-founder of Gossiptel. A founder member of the UK Internet Telephony Providers Association (ITSPA), he has been closely involved with the implementation and regulation of new internet based telephony systems for past five years. He is a fervent believer in the power of disruptive communications technology and the role of open source components in the shaping of future telecommunications architectures. MICHEL DE BOER, TWINKLEPHONE Michel de Boer is the lead developer of Twinkle. He has a degree in computer science at the Vrije Universiteit in Amsterdam. His professional background is in software development and technical support of circuit and packet switched voice networks. His area of expertise is in signalling protocols and TCP/IP. Other interests include SIP, open source and Linux. DAVID BRYAN, FOUNDER OF SIPEERIOR David Bryan is a leading expert in the area of P2P SIP. He plays an active role in IETF P2P SIP efforts, and has published numerous academic papers and trade articles on the subject. David is active in the SIP community, including heading up p2psip.org, the leading community site for P2P SIP, and is involved with SIPFoundry, the reSIProcate project, and Vovida.org. David was co-founder and CTO of Jasomi Networks, and previously worked at Cisco Systems and Vovida Networks. David holds a master's degree in Computer Science and is completing a Ph.D. at William and Mary. ADRIAN GEORGESCU, FOUNDER OF AG PROJECTS Adrian Georgescu is Founder and CEO of AG Projects. Based in the Netherlands, AG Projects is a leading European company supplying service providers with turnkey SIP infrastructure systems. Adrian is an advocate of IETF standards, member of OpenSER management board, founder and co-chair of the Dutch ISOC SIP Special Interest Group. Prior to starting of his own company, Adrian had accumulated experience with Tomrad Communications, Esprit Telecom, GTS, Ebone and KPNQwest. Adrian's expertise is the design of high-availability infrastructures, addressing and numbering systems, signaling protocols, provisioning and mediation systems, implementation of disaster recovery plans. Adrian has received in 1996 a degree in Electrical Engineering from Faculty of Electrotechnics at the Polytechnic University of Bucharest, Romania.Founder of AG Projects BERT HUBERT, POWERDNS Bert Hubert is founder of PowerDNS. PowerDNS is shipped with nearly every Linux distribution and comes standard with many wireless routers. Bert is also a long term open source contributor. Among other, he is the author of the Linux Advanced Routing & Traffic Control HOWTO. As a student he developed an application for monitoring large numbers of cable modems and their network performance (using a modified 'pathchar' algorithm), which was sold to several major cable companies. This success caused Bert to drop out of university and concentrate on his own company, PowerDNS. Netherlabs is a consulting company specialised in networking, telephony, UNIX/Linux, system development and requirement planning. YTSEN KOOISTRA, YBK Ytsen is an independant consultant. He founded Rits tele.com, one of the first VoIP providers in The Netherlands and sold the company to BBned in 2005. Now he's working for telecommunications companies and service providers in the area of regulatory affairs and (technical) business development. Ytsen studied at the TU Delft. OLAF KOLKMAN, NLNET LABS Olaf Kolkman is director of NLnet Labs and a member of the Internet Architecture Board. He was trained as an astronomer but his interest in Internet technology took hold of his career path around 1996. He joined the RIPE NCC around 1997 where he got involved in the test-traffic project. That project brought him in contact with the IETF and he attended his first meeting in Munich. After acting as operations manager for a while he became systems architect, responsible for DNSSEC deployment at the NCC, in 2000. From that time on he has been active in the DNS community for instance as co-chair of the DNSEXT working group. He joined NLnet Labs, a R&D foundation, as chief executive in 2005. He is an IAB member since March 2006. DAN PASCU, CTO AG PROJECTS Dan Pascu received a Bachelor of Science in Electronics and Telecommunications from Bucharest Polytechnic University in 1995. Dan has years of experience in design and implementation of complex systems, software development and IP networking. Dan is a well-known contributor to the Open Source community, he is co-author of WindowMaker X-Window Manager and author of MediaProxy solution for SIP Express Router. HENDRIK ROOD, STRATIX Hendrik Rood is a senior consultant at Stratix Consulting since 1995. He was also a Senior Research Fellow at Economics of Infrastructures section at Delft University of Technology from 1998 - 2006. He has regularly published on the economics of names, numbers and other identifiers on electronic networks and on interconnection issues in scientific journals and conferences. At Stratix Hendrik specialised in technical network architecture design and procurement, regulatory advisory services and business plan due dilligence for financial sector clients. He assists a broad range of clients in more informed decision making in telecommunications, Internet and media questions. Hendrik has a background in high bit-rate transmission systems engineering (land-based and submarine systems) and public switching telephony networks. Voice-over-IP and ENUM is an area where he is keen to use his IP networking and classical telecoms background and his non-technical experience in the industry to discuss development questions. ANTOIN VERSCHUREN, SIDN/SEN Antoin Verschuren works as a technical advisor for the Policy & Business Development department of Stichting Internet Domeinregistratie Nederland. SIDN governs the .nl-domain. Before that he was a member of the advisory council of SIDN for several years. Prior functions include Via Networks and Internet Access Eindhoven in several technical functions. MICHIEL LEENAARS, INTERNET SOCIETY Michiel Leenaars is director of Internet Society Netherlands since 2002. ISOC Netherlands is the largest ISOC-chapter in the world. He is a member of the Strategic Committee of Eurid, the .eu registry, of the Netherlands shadow committee of JTC 1/SC 34, the advisory committee of Burger(a)overheid.nl. He is a a boardmember of stichting Petities.nl and a founding board member of Gridforum Netherlands. He has a academic background in Physics and Arts. Additionally Michiel Leenaars works for the Netherlands Organisation for Scientific Research (NWO) as an advisor on e-science, e-infrastructure and grid technology. He is project leader deputy of e-IRGSP, an EU funded project delivering policy support to the e-Infrastructures Reflection Group (e-IRG) and lead editor of the e-Infrastructures Roadmap publised by e-IRG.

1 0