- enum-wg - mailman.ripe.net

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