From agm at ripe.net Wed Oct 3 14:42:04 2007 From: agm at ripe.net (Axel Pawlik) Date: Wed, 03 Oct 2007 14:42:04 +0200 Subject: [ncc-services-wg] Reminder: RIPE NCC General Meeting - 24 October 2007 Message-ID: <47038E1C.60909@ripe.net> [Apologies for duplicates] Dear RIPE NCC member, The Executive Board of the RIPE NCC Association invites you to the General Meeting (GM) of the RIPE NCC membership. The GM will be held on 24 October 2007 at the Krasnapolsky Hotel from 17:45 - 19:00 adjacent to the RIPE 55 meeting in Amsterdam, the Netherlands. Detailed information about the GM is available at: http://www.ripe.net/membership/gm/gm-october2007/index.html REGISTRATION ------------ The GM is open only to RIPE NCC members. Registration for the RIPE Meeting does not include registration for the GM. You must register separately. You can attend the RIPE NCC Services Working Group session held during RIPE 55 and the GM without being registered for RIPE 55. You can register online for the GM at: https://lirportal.ripe.net/lirportal/meeting/registration-general/meeting.html?id=48 Please complete the online registration form before 10 October 2007. In the event that your organisation is to be represented by a director or an employee, for example an administrative or technical contact, the registration form should state the name(s) of the employee(s) or director(s). If more than one authorised person is to attend the GM, please specify who is allowed to exercise the voting rights. Agenda ------ The agenda for the RIPE NCC GM is available at: http://www.ripe.net/membership/gm/gm-october2007/agenda.html Proxy Form ---------- If your organisation is to be represented by a third party, not being an authorised employee or director, please fill out the proxy form and send it to us before 10 October 2007. Any proxy sent to us after this date will not be valid. The proxy form is available to download here: http://www.ripe.net/membership/gm/gm-october2007/proxy.html Report from the RIPE NCC ------------------------ The report from the RIPE NCC will be presented during the RIPE NCC Services Working Group session during RIPE 55. GM attendees who have not registered for the RIPE Meeting are welcome to participate in this working group session. This takes place on Wednesday, 24 October 2007 from 16:00 - 17:30, immediately before the GM. The RIPE NCC reports will not be repeated in the GM. Voting and Resolutions ---------------------- Candidate members are welcome to attend the GM but are not permitted to vote according to article 16.7 of the RIPE NCC Articles of Association. Members who are not able to attend the GM but still want to vote can do so by means of proxy voting as per article 16. Please also note that the GM can only pass resolutions that have been submitted and published according to article 15 of the RIPE NCC Articles of Association. The RIPE NCC Articles of Association can be found at: http://www.ripe.net/ripe/docs/articles-association.html If you have any questions about the GM please e-mail us at agm at ripe.net. Regards, Axel Pawlik Managing Director RIPE NCC Important Dates 26 September 2007 GM registration opens 26 September 2007 Agenda and proposed resolutions online 10 October 2007 Submission deadline for proposed resolutions 10 October 2007 GM and proxy vote registration encouraged by this date 26 October 2007 RIPE NCC General Meeting October 2007 From ondrej.sury at nic.cz Thu Oct 4 13:00:07 2007 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 04 Oct 2007 13:00:07 +0200 Subject: [ncc-services-wg] DNSMON policy proposal change Message-ID: <1191495607.11795.31.camel@yuna> 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 at 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 at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: ripe-342.diff Type: text/x-patch Size: 5397 bytes Desc: not available URL: -------------- next part -------------- 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 Helpdesk/ NOC dnsmon at ripe.net Emergency contact ops at ripe.net Finance/ billing contact finance at 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 at 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 at 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) From pk at DENIC.DE Thu Oct 4 15:04:32 2007 From: pk at DENIC.DE (Peter Koch) Date: Thu, 4 Oct 2007 15:04:32 +0200 Subject: [ncc-services-wg] DNSMON policy proposal change In-Reply-To: <1191495607.11795.31.camel@yuna> References: <1191495607.11795.31.camel@yuna> Message-ID: <20071004130432.GA13585@denics7.denic.de> On Thu, Oct 04, 2007 at 01:00:07PM +0200, Ond??ej Sur?? wrote: > policy. I am also attaching new document (ripe-342-1.txt), and diff > between this and current policy (ripe-342.diff). judging from previous discussion I do not expect much controversy on the overall direction, so hopefully touching upon wording isn't premature: > +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. I'm not too comfortable seeing the term "TLD" extended into ENUM land. Also, even if "Tier 0/1/2" usually denotes the registry instead of the domain or zone, we should speak of ENUM Tier 1 domains, just as we - on purpose - say "TLD" instead of "Domain". The term "delegated" in (b), while technically perfectly OK, might undergo the same polishing applied to (a). > * the Test Box Hosts, > - * the operators of the root servers and TLD servers, > + * the operators of the root servers, TLD and ENUM domain servers, > * the Internet community in general. ENUM Tier1 Domain name servers, similar below ... > -The RIPE NCC will include the servers of a TLD in the service if that > -TLD Administrator asks for it. Servers of a TLD 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 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. > +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. Unrelated to the proposed change: how can a TB be "located inside a TLD"? > 3.1. Definitions > > - a. TLD Administrator: The organisation(s) responsible for the > - registry of a Top Level Domain, as recorded by the IANA. > + a. TLD: Top Level Domain, as recorded by the IANA, or delegated domain > + corresponding to E.164 country code, as delegated by RIPE NCC. This definition collides with the one provided 0.a. As stated above, we should keep the distinction of TLD and ENUM Tier 1. -Peter PS: Thinking of implementation, the domain overview page is sorted alphabetically, giving preference to the e164.arpa domains right now. Maybe some grouping of ccTLD and e164.arpa (where appropriate) could increase legibility. From henk at ripe.net Thu Oct 4 16:57:47 2007 From: henk at ripe.net (Henk Uijterwaal) Date: Thu, 04 Oct 2007 16:57:47 +0200 Subject: [ncc-services-wg] DNSMON policy proposal change In-Reply-To: <20071004130432.GA13585@denics7.denic.de> References: <1191495607.11795.31.camel@yuna> <20071004130432.GA13585@denics7.denic.de> Message-ID: <4704FF6B.9080402@ripe.net> Peter, others, >> -The RIPE NCC will include the servers of a TLD in the service if that >> -TLD Administrator asks for it. Servers of a TLD 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 servers to be >> -monitored. > Unrelated to the proposed change: how can a TB be "located inside a TLD"? What we meant was, even though the wording is perhaps a bit unlucky, that the hosts of TB inside country XX may ask DNSMON to monitor the .XX domain. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Is one of the choices leaving the office open? Alan Greenspan on the next elections From pk at DENIC.DE Thu Oct 4 18:45:37 2007 From: pk at DENIC.DE (Peter Koch) Date: Thu, 4 Oct 2007 18:45:37 +0200 Subject: [ncc-services-wg] DNSMON policy proposal change In-Reply-To: <4704FF6B.9080402@ripe.net> References: <1191495607.11795.31.camel@yuna> <20071004130432.GA13585@denics7.denic.de> <4704FF6B.9080402@ripe.net> Message-ID: <20071004164537.GB9178@denics7.denic.de> Henk, > What we meant was, even though the wording is perhaps a bit unlucky, that > the hosts of TB inside country XX may ask DNSMON to monitor the .XX domain. now that you say it! Apologies for the misreading. -Peter From jim at rfc1035.com Thu Oct 4 15:34:17 2007 From: jim at rfc1035.com (Jim Reid) Date: Thu, 4 Oct 2007 14:34:17 +0100 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains Message-ID: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> Ondrej, I raised a number of issues about this proposal when you first presented this to the ENUM WG. To the best of my knowledge these have still not been resolved. Wearing no hats, my concerns are as follows: 1 DNS Monitoring is not a core NCC service. It should not be doing this IMO. It's OK for the NCC to monitor its own name servers, but that's all. 2 By offering a commercial DNS Monitoring service, the NCC is distorting the market. Its presence presents other organisations from offering similar services because the barrier to entry has been artificially increased. And on top of that the NCC has cherry-picked the best customers. 3 The costs of the NCC's DNS monitoring service are not clear. Which raises the prospect of complaints about monopoly membership fees cross-subsidising non-core commercial activities. This is a particular worry of mine given that the NCC's initial investment in name server monitoring was met from its membership fees. 4 If any monitoring of ENUM delegations was to be done by the NCC, it must only be at the request of the Administration concerned. This avoids issues about national sovereignty. I accept this is unlikely to be a concern for many countries. But that will not be the case in the parts of the world that are hostile to Internet governance in its broadest sense being outside an international treaty organisation. It would not be wise IMO to open another window for those sorts of complaints and attacks. Issues 1-3 have parallels with the historical situation of the NCC providing DNS service for ccTLDs. That situation is beginning to get untangled. And for the same reasons outlined above: non-core service, competition concerns, cross-subsidy, etc. It seems unwise to be opening up the same can of worms all over again just as an earlier one is starting to get cleared up. From BSanghani at flagtelecom.com Fri Oct 5 17:15:25 2007 From: BSanghani at flagtelecom.com (Sanghani, Bijal) Date: Fri, 5 Oct 2007 20:45:25 +0530 Subject: [ncc-services-wg] RIPE55 Draft Agenda for NCC Service WG Message-ID: <147955311569D511AD0D00508B667530062498F5@lon-emailcl.flagtelecom.com> Dear All, Please see below updated draft agenda for NCC Services WG - RIPE 55 - DRAFT RIPE NCC Services Working Group Agenda A. Administrative Matters * Welcome * Select a scribe * Distribute participants list * Finalise agenda * Approve Minutes: RIPE 54 B. RIPE NCC Update, Vision and Focus 2008: Proposed Changes to Activities in 2008 - Axel Pawlik (RIPE NCC) C. Update on Training Services - Rumy Kanis D. Proposal to change DNSMON policy - Ondrej Sury E. Open Mic. Session D. AOB Regards, Bijal _____ From: Sanghani, Bijal [mailto:BSanghani at flagtelecom.com] Sent: 25 September 2007 09:14 To: 'ncc-services-wg at ripe.net' Subject: [ncc-services-wg] RIPE55 Draft Agenda for NCC Service WG Dear All, Please see below the draft agenda for the NCC Services WG - RIPE 55 - DRAFT RIPE NCC Services Working Group Agenda A. Administrative Matters * Welcome * Select a scribe * Distribute participants list * Finalise agenda * Approve Minutes: RIPE 54 B. RIPE NCC Update, Vision and Focus 2008: Proposed Changes to Activities in 2008 - Axel Pawlik (RIPE NCC) C. Update on Training Services - Rumy Kanis D. Open Mic. Session D. AOB Regards, Bijal _____ From: Sanghani, Bijal [mailto:BSanghani at flagtelecom.com] Sent: 28 August 2007 11:45 To: 'ncc-services-wg at ripe.net' Cc: wg-chairs at ripe.net Subject: [ncc-services-wg] RIPE 55 Agenda Items Dear All, Its 8 weeks till the next RIPE meeting and we've started compiling items for the draft agenda for the NCC Services working group. If anyone would like to suggest a presentation or raise a topic for discussion please let either Kurtis or me know and we'll arrange a spot on the agenda for you. Regards, Bijal -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at nosignal.org Sat Oct 6 11:43:55 2007 From: andy at nosignal.org (Andy Davidson) Date: Sat, 6 Oct 2007 10:43:55 +0100 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> References: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> Message-ID: <5500EBE1-E080-4A31-A475-2959733BF6B6@nosignal.org> On 4 Oct 2007, at 14:34, Jim Reid wrote: > 1 DNS Monitoring is not a core NCC service. It should not be doing > this IMO. It's OK for the NCC to monitor its own name servers, but > that's all. Disagree - the NCC is community led, and provides infrastructure services (including, but not limited to numbering resources) to the community. I strongly value the quality of independent data I receive as a stakeholder from services like DNSMON, but also TTM and RIS. Although my LIR could realistically have done everything it 'needed to' from a resource point of view with ripe through another LIR, we joined because we value the work of the NCC in areas away from numbering resources. > 2 By offering a commercial DNS Monitoring service, the NCC is > distorting the market. Its presence presents other organisations > from offering similar services because the barrier to entry has > been artificially increased. And on top of that the NCC has cherry- > picked the best customers. I think DNSMON is used for something completely different to real commercial monitoring services like alertsite.com and similar. Furthermore, can I get information about the availability/quality of root servers from the commercial guys ? For free ? I use this data from time to time, as do many more people in the community at large, and if RIPE didn't do it, someone else would. RIPE do it extremely well, and have the historical data - please let them continue. > 3 The costs of the NCC's DNS monitoring service are not clear. > Which raises the prospect of complaints about monopoly membership > fees cross-subsidising non-core commercial activities. This is a > particular worry of mine given that the NCC's initial investment in > name server monitoring was met from its membership fees. I don't have data to comment on this - but see my reply to (1) - we joined because we wanted to support the RIPE community work, as well as needing access to numbering resources. Best wishes, Andy Davidson From ondrej.sury at nic.cz Mon Oct 8 11:29:49 2007 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Mon, 08 Oct 2007 11:29:49 +0200 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> References: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> Message-ID: <1191835789.14876.21.camel@yuna> Jim Reid p??e v ?t 04. 10. 2007 v 14:34 +0100: > Ondrej, I raised a number of issues about this proposal when you > first presented this to the ENUM WG. To the best of my knowledge > these have still not been resolved. > > Wearing no hats, my concerns are as follows: > > 1 DNS Monitoring is not a core NCC service. It should not be doing > this IMO. It's OK for the NCC to monitor its own name servers, but > that's all. > > 2 By offering a commercial DNS Monitoring service, the NCC is > distorting the market. Its presence presents other organisations from > offering similar services because the barrier to entry has been > artificially increased. And on top of that the NCC has cherry-picked > the best customers. > > 3 The costs of the NCC's DNS monitoring service are not clear. Which > raises the prospect of complaints about monopoly membership fees > cross-subsidising non-core commercial activities. This is a > particular worry of mine given that the NCC's initial investment in > name server monitoring was met from its membership fees. I understand your concerns in Issue 1-3, but it seems to me, that you are arguing with DNSMON service itself and not with my proposal which is meant to broaden scope of DNSMON service. > 4 If any monitoring of ENUM delegations was to be done by the NCC, it > must only be at the request of the Administration concerned. This > avoids issues about national sovereignty. I accept this is unlikely > to be a concern for many countries. But that will not be the case in > the parts of the world that are hostile to Internet governance in its > broadest sense being outside an international treaty organisation. It > would not be wise IMO to open another window for those sorts of > complaints and attacks. Can you please clarify what do you mean by "at the request of the Administration concerned"? Who is Administration? Tier-1 operator? > Issues 1-3 have parallels with the historical situation of the NCC > providing DNS service for ccTLDs. That situation is beginning to get > untangled. And for the same reasons outlined above: non-core service, > competition concerns, cross-subsidy, etc. It seems unwise to be > opening up the same can of worms all over again just as an earlier > one is starting to get cleared up. 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 at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From ondrej.sury at nic.cz Mon Oct 8 11:37:10 2007 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Mon, 08 Oct 2007 11:37:10 +0200 Subject: [ncc-services-wg] DNSMON policy proposal change In-Reply-To: <20071004130432.GA13585@denics7.denic.de> References: <1191495607.11795.31.camel@yuna> <20071004130432.GA13585@denics7.denic.de> Message-ID: <1191836230.14876.29.camel@yuna> Peter Koch p??e v ?t 04. 10. 2007 v 15:04 +0200: > On Thu, Oct 04, 2007 at 01:00:07PM +0200, Ond??ej Sur?? wrote: > > > policy. I am also attaching new document (ripe-342-1.txt), and diff > > between this and current policy (ripe-342.diff). > > judging from previous discussion I do not expect much controversy on the > overall direction, so hopefully touching upon wording isn't premature: > > > +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. > > I'm not too comfortable seeing the term "TLD" extended into ENUM land. > Also, even if "Tier 0/1/2" usually denotes the registry instead of the > domain or zone, we should speak of ENUM Tier 1 domains, just as we - on purpose - > say "TLD" instead of "Domain". The term "delegated" in (b), while technically > perfectly OK, might undergo the same polishing applied to (a). I tried to change as few words as possible. We could change b) and c) to: a. TLD: A Top Level Domain, as recorded by the IANA. b. ENUM Tier-1 domain: A delegated domain corresponding to E.164 country code, as delegated by RIPE NCC. c. Administrator: The organisation(s) responsible for the registry of a TLD or ENUM Tier-1 domain. > > * the Test Box Hosts, > > - * the operators of the root servers and TLD servers, > > + * the operators of the root servers, TLD and ENUM domain servers, > > * the Internet community in general. > > ENUM Tier1 Domain name servers, similar below ... * the operators of the root servers, TLD and ENUM Tier-1 domain servers, > > 3.1. Definitions > > > > - a. TLD Administrator: The organisation(s) responsible for the > > - registry of a Top Level Domain, as recorded by the IANA. > > + a. TLD: Top Level Domain, as recorded by the IANA, or delegated domain > > + corresponding to E.164 country code, as delegated by RIPE NCC. > > This definition collides with the one provided 0.a. As stated above, we > should keep the distinction of TLD and ENUM Tier 1. Maybe we could replace TLD with something like "Monitored Domain"? Again I tried to change as few words as possible. Replacing all "TLD" with "TLD and ENUM Tier-1 domain" doesn't improve readability of the document (and the contract) at all. 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 at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From Ian.Meikle at nominet.org.uk Mon Oct 8 12:16:46 2007 From: Ian.Meikle at nominet.org.uk (Ian Meikle) Date: Mon, 8 Oct 2007 11:16:46 +0100 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: <5500EBE1-E080-4A31-A475-2959733BF6B6@nosignal.org> Message-ID: ncc-services-wg-admin at ripe.net wrote on 06/10/2007 10:43:55: > > On 4 Oct 2007, at 14:34, Jim Reid wrote: > > > > 2 By offering a commercial DNS Monitoring service, the NCC is > > distorting the market. Its presence presents other organisations > > from offering similar services because the barrier to entry has > > been artificially increased. And on top of that the NCC has cherry- > > picked the best customers. > > I think DNSMON is used for something completely different to real > commercial monitoring services like alertsite.com and similar. > Furthermore, can I get information about the availability/quality of > root servers from the commercial guys ? For free ? I use this data > from time to time, as do many more people in the community at large, > and if RIPE didn't do it, someone else would. RIPE do it extremely > well, and have the historical data - please let them continue. > I just wanted to add my voice to the discussion. We rely on the data provided by DNSMON to monitor the global reachability of the .uk nameservers. The tool is used to assess our performance against KPIs and as a diagnostic tool. Given its usefulness I would certainly want to extend it to monitor ENUM nameservers. I can see the concern that Jim has, but the fact remains: If the service is not provided by RIPE, who would provide it? Who else has the traffic measurement boxes so well distributed? Not to mention the professional resources and experience. Regards, Ian From jim at rfc1035.com Mon Oct 8 12:59:22 2007 From: jim at rfc1035.com (Jim Reid) Date: Mon, 8 Oct 2007 11:59:22 +0100 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: References: Message-ID: <2351D9B9-9B80-40E3-A896-B52CF27B500F@rfc1035.com> On Oct 8, 2007, at 11:16, Ian Meikle wrote: > If the service is not provided by RIPE, who would provide it? > Who else has the traffic measurement boxes so well > distributed? Not to mention the professional resources and experience. I believe Verisign uses its global DNS infrastructure to monitor the root servers, as do some of the other root service operators. [Besides the NCC. :-)] UltraDNS/Neustar monitor their global DNS platform. And I expect Afilias would be in a position to offer this service once their anycast infrastructure is fully deployed. Presumably these organisations would be prime candidates to offer a DNS monitoring service if there was a level playing field. CAIDA has monitoring boxes deployed all over the place, though they may be unable to get involved in commercial activities or deliver "service". Another possibility could be for CENTR to offer this service to its members. Maybe ICANN/IANA could do this? Shouldn't they be gathering statistics on the health of the DNS and keeping track of critical DNS infrastructure? Your remarks about "professional resources and experience" are particularly troubling for me Ian. It can (and may well be argued) that the NCC's presence in this emerging market is stifling others from offering DNS monitoring services and creates an artificial barrier to entry. That makes it harder for a competitor to pay for equipment, staff and gain operational experience. And meanwhile the NCC has cherry-picked the best (and probably the richest) customers. This is why I drew parallels with the NCC's DNS hosting service. In the early days of the net, it made sense for the NCC to host TLDs. Now it doesn't. So the NCC is gracefully exiting that "business". Entering the DNS monitoring business -- and watch the mission creep that's happened here! -- looks to be a repeat of those earlier well- meaning but misplaced intentions. From jim at rfc1035.com Mon Oct 8 13:14:45 2007 From: jim at rfc1035.com (Jim Reid) Date: Mon, 8 Oct 2007 12:14:45 +0100 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: <1191835789.14876.21.camel@yuna> References: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> <1191835789.14876.21.camel@yuna> Message-ID: On Oct 8, 2007, at 10:29, Ond?ej Sur? wrote: > I understand your concerns in Issue 1-3, but it seems to me, that you > are arguing with DNSMON service itself and not with my proposal > which is > meant to broaden scope of DNSMON service. That's absolutely correct Ond?ej. However the two things are linked. It will be harder and more expensive for the NCC to exit the DNS monitoring business -- as it will surely have to do eventually -- if the DNSMON service has strayed even further from its initial purpose. Which, IIRC, was to monitor the NCC's own DNS infrastructure. > Can you please clarify what do you mean by "at the request of the > Administration concerned"? Who is Administration? Tier-1 operator? I was deliberately vague here. :-) It could be the Tier-1 operator. Or it might be the government/regulator. It depends on the national circumstances. .e164.arpa is a National Resource, just like a country's territory and air space. Nobody should be poking around in .e164.arpa without proper authority. Just like we usually have to show passports when crossing borders. From Ian.Meikle at nominet.org.uk Mon Oct 8 13:21:17 2007 From: Ian.Meikle at nominet.org.uk (Ian Meikle) Date: Mon, 8 Oct 2007 12:21:17 +0100 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: <2351D9B9-9B80-40E3-A896-B52CF27B500F@rfc1035.com> Message-ID: ncc-services-wg-admin at ripe.net wrote on 08/10/2007 11:59:22: > On Oct 8, 2007, at 11:16, Ian Meikle wrote: > > > If the service is not provided by RIPE, who would provide it? > > Who else has the traffic measurement boxes so well > > distributed? Not to mention the professional resources and experience. > > I believe Verisign uses its global DNS infrastructure to monitor the > root servers, as do some of the other root service operators. > [Besides the NCC. :-)] UltraDNS/Neustar monitor their global DNS > platform. And I expect Afilias would be in a position to offer this > service once their anycast infrastructure is fully deployed. > Presumably these organisations would be prime candidates to offer a > DNS monitoring service if there was a level playing field. CAIDA has > monitoring boxes deployed all over the place, though they may be > unable to get involved in commercial activities or deliver "service". > Another possibility could be for CENTR to offer this service to its > members. Maybe ICANN/IANA could do this? Shouldn't they be gathering > statistics on the health of the DNS and keeping track of critical DNS > infrastructure? > Are these commercial offerings? We are a customer of UltraDNS/Neustar for DNS provision and it has never been suggested that we use their monitoring services. Any new service from Centr or ICANN/IANA would (a) take too long to set up, and (b) be subject to the same arguments you are making against DNSMON. > Your remarks about "professional resources and experience" are > particularly troubling for me Ian. It can (and may well be argued) > that the NCC's presence in this emerging market is stifling others > from offering DNS monitoring services and creates an artificial > barrier to entry. That makes it harder for a competitor to pay for > equipment, staff and gain operational experience. And meanwhile the > NCC has cherry-picked the best (and probably the richest) customers. > Sorry to worry you Jim ;-) What I was trying to point out was that this is already an established service, widely used by the RIPE LIR community and beyond. If we prevent it being extended to ENUM then we are left without a viable way of monitoring those nameservers. > This is why I drew parallels with the NCC's DNS hosting service. In > the early days of the net, it made sense for the NCC to host TLDs. > Now it doesn't. So the NCC is gracefully exiting that "business". > Entering the DNS monitoring business -- and watch the mission creep > that's happened here! -- looks to be a repeat of those earlier well- > meaning but misplaced intentions. I see a difference here. DNS hosting is an established field in which there are numerous providers. I am not aware of any other providers of a service similar to DNSMON. It may be that the market is not mature enough yet. In that case, if RIPE is the only place we can go to for this then let us use it. Ian From jim at rfc1035.com Mon Oct 8 14:00:03 2007 From: jim at rfc1035.com (Jim Reid) Date: Mon, 8 Oct 2007 13:00:03 +0100 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: References: Message-ID: > Are these commercial offerings? We are a customer of UltraDNS/ > Neustar for > DNS provision and it has never been suggested that we use their > monitoring > services. Has anyone asked for a quote? > Any new service from Centr or ICANN/IANA would (a) take too long > to set up, and (b) be subject to the same arguments you are making > against > DNSMON. I don't agree the same arguments could be made. But even if they were, that would be a problem for the organisation concerned. It wouldn't be the NCC's problem. :-) > Sorry to worry you Jim ;-) What I was trying to point out was that > this is > already an established service, widely used by the RIPE LIR > community and > beyond. If we prevent it being extended to ENUM then we are left > without a > viable way of monitoring those nameservers. REALLY?!?! Are you seriously telling me that Nominet cannot monitor the UK's ENUM servers without buying DNSMON? I very much hope not.... What did Nominet do to keep an eye on the .uk name servers before DNSMON came along? Besides, whether DNSMON is widely used or not is beside the point. It's not a core NCC activity. If the NCC spins off DNSMON into an independent, self-funded entity, that's fine. But when DNSMON is part of a monopoly RIR and (partly?) funded from that monopoly's membership fees.... We can see where that is headed. And that's before we consider the competition aspects. > I see a difference here. DNS hosting is an established field in which > there are numerous providers. I am not aware of any other providers > of a > service similar to DNSMON. It may be that the market is not mature > enough > yet. In that case, if RIPE is the only place we can go to for this > then > let us use it. I've suggested a number of other possibilities. Perhaps they could be approached? There might be a stronger case for DNSMON if it could be shown that nobody else was willing or able to provide the service at a reasonable price. Your comments about the market not being mature are very true Ian. This is all the more reason for the NCC to keep out. Its presence deters others from coming forward and prevents a free, competitive market from being established. Your argument is a bit like saying everybody should support Manchester United because they're the biggest and most successful team with the best players. Which I know will annoy you Ian as your football affiliations rest elsewhere... :-) From Ian.Meikle at nominet.org.uk Mon Oct 8 14:57:35 2007 From: Ian.Meikle at nominet.org.uk (Ian Meikle) Date: Mon, 8 Oct 2007 13:57:35 +0100 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: Message-ID: ncc-services-wg-admin at ripe.net wrote on 08/10/2007 13:00:03: > > Are these commercial offerings? We are a customer of UltraDNS/ > > Neustar for > > DNS provision and it has never been suggested that we use their > > monitoring > > services. > > Has anyone asked for a quote? > I didn't know there was a service there, so I'm unlikely to ask for a quote. > > Any new service from Centr or ICANN/IANA would (a) take too long > > to set up, and (b) be subject to the same arguments you are making > > against > > DNSMON. > > I don't agree the same arguments could be made. But even if they > were, that would be a problem for the organisation concerned. It > wouldn't be the NCC's problem. :-) > > > Sorry to worry you Jim ;-) What I was trying to point out was that > > this is > > already an established service, widely used by the RIPE LIR > > community and > > beyond. If we prevent it being extended to ENUM then we are left > > without a > > viable way of monitoring those nameservers. > > REALLY?!?! Are you seriously telling me that Nominet cannot monitor > the UK's ENUM servers without buying DNSMON? I very much hope not.... > What did Nominet do to keep an eye on the .uk name servers before > DNSMON came along? > You are wilfully misunderstanding me here. We can and do monitor our nameservers. What we can't get is the global picture that DNSMON provides, and this allows us to determine the scope of any incident affecting them. Anyway, the argument here is not whether a service to monitor nameservers is required, but who provides it. > Besides, whether DNSMON is widely used or not is beside the point. > It's not a core NCC activity. If the NCC spins off DNSMON into an > independent, self-funded entity, that's fine. But when DNSMON is part > of a monopoly RIR and (partly?) funded from that monopoly's > membership fees.... We can see where that is headed. And that's > before we consider the competition aspects. > We are approaching this from different angles. As the operator of a major DNS infrastructure I want to use whatever systems are available to ensure I have the best view of that infrastructure. I also want to be able to extend those systems to monitoring my new DNS infrastructure. I presume you are speaking as a RIPE NCC board member, and I think it is valuable to raise the point of a potential monopoly. But still, DNSMON exists and nothing else comes close. If we aren't able to extend it to cover new services then they will (potentially) be poorer as a result. > > I see a difference here. DNS hosting is an established field in which > > there are numerous providers. I am not aware of any other providers > > of a > > service similar to DNSMON. It may be that the market is not mature > > enough > > yet. In that case, if RIPE is the only place we can go to for this > > then > > let us use it. > > I've suggested a number of other possibilities. Perhaps they could be > approached? There might be a stronger case for DNSMON if it could be > shown that nobody else was willing or able to provide the service at > a reasonable price. > I'm willing to consider other providers. But even if there were other services I would continue to use DNSMON. > Your comments about the market not being mature are very true Ian. > This is all the more reason for the NCC to keep out. Its presence > deters others from coming forward and prevents a free, competitive > market from being established. > > Your argument is a bit like saying everybody should support > Manchester United because they're the biggest and most successful > team with the best players. Which I know will annoy you Ian as your > football affiliations rest elsewhere... :-) Notts County (http://en.wikipedia.org/wiki/Notts_County) are the oldest professional football club in the world. They are not the biggest today by quite some way. I don't want to take the football analogy too far, but it shows that things change. It may be that someone can provide a better service and DNSMON will be eclipsed. Until then I want to be able to use it. From sjoerdoo at ripe.net Mon Oct 8 15:28:13 2007 From: sjoerdoo at ripe.net (Sjoerd Oostdijck) Date: Mon, 08 Oct 2007 15:28:13 +0200 Subject: [ncc-services-wg] DNS Maintenance on ns.ripe.net, 10 Okt Message-ID: <470A306D.6090807@ripe.net> [Apologies for duplicate e-mails.] Dear Colleagues, On Wednesday, 10 Oktober 2007, we will update our DNS server ns.ripe.net between 17:00 and 18:00 (UTC). During this period, it will not be able to answer DNS queries. We apologise for any inconvenience this may cause. If you have any questions or concerns about this, please send an e-mail to . Regards, Sjoerd Oostdijck, DNS Services RIPE NCC From jim at rfc1035.com Mon Oct 8 15:33:56 2007 From: jim at rfc1035.com (Jim Reid) Date: Mon, 8 Oct 2007 14:33:56 +0100 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: References: Message-ID: <3678E9F7-3B2E-44EC-83B8-F0A5BAA5845F@rfc1035.com> On Oct 8, 2007, at 13:57, Ian Meikle wrote: > I presume you are speaking as a RIPE NCC board member Nope. I am speaking as a concerned member of the public. As someone who's had the NCC literally each my lunch by offering "free" DNSSEC training courses. And as a former employee of an LIR who saw their membership fees being used by the NCC to nurture DNS software that undermined that company's products. If the NCC continues to dabble in these sorts of non-core activities, it will eventually attract unwanted attention from regulators and competition authorities. Extending the scope of DNSMON is the thin edge of a very, very big wedge. BTW, there was a time 4-5 years ago when I considered setting up a DNS monitoring business. I didn't pursue this as the numbers didn't add up for me. The risks were too great and the rewards didn't justify taking them: too much capital outlay and not enough revenue. [Which begs the question about the NCC's sums for DNSMON.] I'm glad I didn't set up that business as the NCC's later entrance into that market would have bankrupted me. And no, this is not sour grapes because someone else has established such a business. Although the board has discussed DNSMON from time to time, it would be quite wrong to suggest that I am speaking for the board on this matter or speaking as a member of the board. If I was, that would be very clearly signalled. From Niall.oReilly at ucd.ie Mon Oct 8 16:02:13 2007 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Mon, 08 Oct 2007 15:02:13 +0100 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: References: Message-ID: On 8 Oct 2007, at 13:00, Jim Reid wrote: > But when DNSMON is part of a monopoly RIR and (partly?) funded from > that monopoly's membership fees.... Is that so? I was given to understand that the costs of the Test Traffic service (of which DNSMON is an optional part) were borne by the subscribers to that service, and not subsidised by membership fees. It is possible either that my recollection is faulty, or that I just misunderstood. /Niall -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From jim at rfc1035.com Mon Oct 8 16:32:16 2007 From: jim at rfc1035.com (Jim Reid) Date: Mon, 8 Oct 2007 15:32:16 +0100 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: References: Message-ID: <960F05AE-7DD4-4850-8415-0E944A7EAB71@rfc1035.com> On Oct 8, 2007, at 15:02, Niall O'Reilly wrote: >> But when DNSMON is part of a monopoly RIR and (partly?) funded >> from that monopoly's membership fees.... > > Is that so? Well it certainly smells that way to anyone that's outside the RIPE goldfish bowl. > I was given to understand that the costs of the Test Traffic service > (of which DNSMON is an optional part) were borne by the subscribers > to that service, and not subsidised by membership fees. I don't know. But I can find out. It may be hard to identify all of these costs: eg what percentage of the heating and electricity bills can be exclusively attributed to Test Traffic activities? From Niall.oReilly at ucd.ie Mon Oct 8 16:54:42 2007 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Mon, 08 Oct 2007 15:54:42 +0100 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: <960F05AE-7DD4-4850-8415-0E944A7EAB71@rfc1035.com> References: <960F05AE-7DD4-4850-8415-0E944A7EAB71@rfc1035.com> Message-ID: <5BE6E6E9-9F42-4F1D-A927-59417BDE089A@ucd.ie> On 8 Oct 2007, at 15:32, Jim Reid wrote: > On Oct 8, 2007, at 15:02, Niall O'Reilly wrote: > >>> But when DNSMON is part of a monopoly RIR and (partly?) funded >>> from that monopoly's membership fees.... >> >> Is that so? > > Well it certainly smells that way to anyone that's outside the RIPE > goldfish bowl. I see a communication issue there, not a reason to avoid offering (or extending) a service. >> I was given to understand that the costs of the Test Traffic service >> (of which DNSMON is an optional part) were borne by the subscribers >> to that service, and not subsidised by membership fees. > > I don't know. But I can find out. That's one approach. Maybe someone who knows will take the hint, and save you the trouble. Point taken about attribution of overhead costs. With appropriate clarity of accounting and communication, this should not be a reason to avoid [... as above ...] either. /Niall -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From Woeber at CC.UniVie.ac.at Mon Oct 8 17:22:53 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 08 Oct 2007 15:22:53 +0000 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: References: Message-ID: <470A4B4D.3060808@CC.UniVie.ac.at> Niall O'Reilly wrote: > > On 8 Oct 2007, at 13:00, Jim Reid wrote: > >> But when DNSMON is part of a monopoly RIR and (partly?) funded from >> that monopoly's membership fees.... > > > Is that so? > > I was given to understand that the costs of the Test Traffic service > (of which DNSMON is an optional part) were borne by the subscribers > to that service, and not subsidised by membership fees. I definitely clear an annual *additional* (to the LIR cost) invoice for the TT-Service and the care-and-feeding of our TTM Box :-) > It is possible either that my recollection is faulty, or that I just > misunderstood. I definitely know that the NCC has spent quite some effort to drastically reduce or eliminate those cross-subsidising things. That's one of the reasons why the att. fees for RIPE Meetings have gone up considerably over the years, and new LIRs get a (2?) voucher/s as part of their sign-up fees. > /Niall I presume this stuff is never perfect or completely done, but IMHO the NCC is fully aware of these issues. Wilfried. From olaf at NLnetLabs.nl Mon Oct 8 17:36:16 2007 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Mon, 8 Oct 2007 11:36:16 -0400 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: <5BE6E6E9-9F42-4F1D-A927-59417BDE089A@ucd.ie> References: <960F05AE-7DD4-4850-8415-0E944A7EAB71@rfc1035.com> <5BE6E6E9-9F42-4F1D-A927-59417BDE089A@ucd.ie> Message-ID: <5F6FB1BF-7D74-48B4-B208-EFA7F22E5326@NLnetLabs.nl> Replying to no-body in particular. The discussion has been framed in terms of a service for particular TLDs or operators. I think that one argument has not been articulated. The DNSMON service has been used in the past to debunk a number of myths about the stability of the the DNS system as a whole. Those myths regularly reappear and may have (global) layer 9 implications. Therefor I think it is important that the data is provided by a monitoring service is ran by a technically competent and neutral party. In that context this task fits in the "the support of the stable operation of the Internet" and I would argue that it is a core activity of the NCC (given that that quote is from Article 3, objectives, of articles of association ;-) ) Since I can imagine that for ENUM there will be myths to be debunked I think that extending the service in that direction (tier 0 and 1 level zones) makes sense. hatless, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 227 bytes Desc: This is a digitally signed message part URL: From andy at nosignal.org Mon Oct 8 17:56:17 2007 From: andy at nosignal.org (Andy Davidson) Date: Mon, 8 Oct 2007 16:56:17 +0100 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: <3678E9F7-3B2E-44EC-83B8-F0A5BAA5845F@rfc1035.com> References: <3678E9F7-3B2E-44EC-83B8-F0A5BAA5845F@rfc1035.com> Message-ID: On 8 Oct 2007, at 14:33, Jim Reid wrote: > On Oct 8, 2007, at 13:57, Ian Meikle wrote: >> I presume you are speaking as a RIPE NCC board member > Nope. I am speaking as a concerned member of the public. We're all well aware of the objections you have as an individual, but each time this topic arises, you see that we don't agree. Perhaps, as an individual, you should take note of this. Your arguments have no support here. Perhaps it's time to accept that? You're also an NCC board member, and as such were elected to represent the views of the membership. Those views are apparant from the messages sent in response to your perpetual opposition, and by consistently protesting, you are failing to represent those views. We've heard the same arguments from you time and time again, and the community rebuff your stance each time. We really appreciate you sharing your opinions with us. We don't agree. You have our collective/community opinion, and it is this which matters :-) Warm wishes, Andy Davidson From jim at rfc1035.com Mon Oct 8 19:44:11 2007 From: jim at rfc1035.com (Jim Reid) Date: Mon, 8 Oct 2007 18:44:11 +0100 Subject: [ncc-services-wg] debate and representation In-Reply-To: References: <3678E9F7-3B2E-44EC-83B8-F0A5BAA5845F@rfc1035.com> Message-ID: I am reluctant to send this so Andy can again criticise me for disagreeing. :-) On Oct 8, 2007, at 16:56, Andy Davidson wrote: > You're also an NCC board member, and as such were elected to > represent the views of the membership. Of course Andy. But I would expect the membership elects its board members to do a lot more than just that. For example by exercising their independent judgement in the best interests of the NCC as a whole. > Those views are apparant from the messages sent in response to your > perpetual opposition, and by consistently protesting, you are > failing to represent those views. If the WG declares consensus for the "community view" on this subject, or anything else for that matter, I will of course as a board member do my best to represent those views as far as I am able to. It's not clear we're at that point yet. However I am very disappointed that you seem to be saying I should just shut up and not be entitled to voice my opinions because they happen to disagree with yours. Or that a board member, even when speaking in a personal capacity, cannot contribute to a WG's discussions or policy-making proposals. There's a valid debate to be had on this subject and its wider implications. This WG would be remiss if it did not allow a reasoned, open exchange of views from all sides. I hope we can at least agree on that. :-) From ian.meikle at nominet.org.uk Mon Oct 8 22:34:01 2007 From: ian.meikle at nominet.org.uk (Ian Meikle) Date: Mon, 8 Oct 2007 21:34:01 +0100 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: <5F6FB1BF-7D74-48B4-B208-EFA7F22E5326@NLnetLabs.nl> Message-ID: ncc-services-wg-admin at ripe.net wrote on 08/10/2007 16:36:16: > > Replying to no-body in particular. > > The discussion has been framed in terms of a service for particular > TLDs or operators. I think that one argument has not been articulated. > > The DNSMON service has been used in the past to debunk a number of > myths about the stability of the the DNS system as a whole. Those > myths regularly reappear and may have (global) layer 9 implications. > Therefor I think it is important that the data is provided by a > monitoring service is ran by a technically competent and neutral party. > > In that context this task fits in the "the support of the stable > operation of the Internet" and I would argue that it is a core > activity of the NCC (given that that quote is from Article 3, > objectives, of articles of association ;-) ) > > Since I can imagine that for ENUM there will be myths to be debunked > I think that extending the service in that direction (tier 0 and 1 > level zones) makes sense. > The point I take from this is that the DNSMON service is transparent. We pay for our service to be monitored, but everyone can see the results of that monitoring, and that motivates us to ensure good service. For us to act in that way we have to have total trust in the impartiality of the organisation providing that service. All the commercial organisations suggested in a previous email (Verisign, Neustar, Afilias) as potential suppliers are also potential commercial rivals to us as a TLD registry. I have no reason to doubt they would act scrupulously, but I would have reservations about using them all the same. The other potential suppliers (Centr, IANA, Caida) would be a closer fit, but none have shown an inclination to offer such a service. Ian From randy at psg.com Mon Oct 8 22:39:29 2007 From: randy at psg.com (Randy Bush) Date: Tue, 09 Oct 2007 05:39:29 +0900 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: References: <3678E9F7-3B2E-44EC-83B8-F0A5BAA5845F@rfc1035.com> Message-ID: <470A9581.9060104@psg.com> > You're also an NCC board member, and as such were elected to represent > the views of the membership. < americal business cultural perspective > board members have a fiduciary duty to the health and direction of the organization, not the interests of a segment of the membership. randy From ripe-wgs.cs at schiefner.de Mon Oct 8 17:45:56 2007 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Mon, 08 Oct 2007 17:45:56 +0200 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: <2351D9B9-9B80-40E3-A896-B52CF27B500F@rfc1035.com> References: <2351D9B9-9B80-40E3-A896-B52CF27B500F@rfc1035.com> Message-ID: <470A50B4.4090806@schiefner.de> Jim, Jim Reid wrote: > [...] Another possibility could be for CENTR > to offer this service to its members. [...] I would be surprised if CENTR all of a sudden would add technical operations to its business. But I guess you used CENTR as a mere placeholder for your example, right? :-) Best, Carsten From andy at nosignal.org Tue Oct 9 16:22:12 2007 From: andy at nosignal.org (Andy Davidson) Date: Tue, 9 Oct 2007 15:22:12 +0100 Subject: [ncc-services-wg] debate and representation In-Reply-To: References: <3678E9F7-3B2E-44EC-83B8-F0A5BAA5845F@rfc1035.com> Message-ID: <68F606BF-D0F6-4FEA-8024-064DD1691A0D@nosignal.org> On 8 Oct 2007, at 18:44, Jim Reid wrote: > However I am very disappointed that you seem to be saying I should > just shut up and not be entitled to voice my opinions because they > happen to disagree with yours. Or that a board member, even when > speaking in a personal capacity, cannot contribute to a WG's > discussions or policy-making proposals. It's hard to differentiate between Jim wearing his jewel encrusted NCC board crown and Jim wearing his tasteful Lochcarron beret tam - can you really offer a truly impartial viewpoint on a matter which has caused you both personal and professional angst, and in which you have an NCC board interest ? While I realise you are making valid points, I genuinely think you're damaging your professional integrity by pushing this argument which has a waft of sour grapes to it. I'm truly surprised that your board colleagues allow this to continue unchecked - you hurt them and yourself. > There's a valid debate to be had on this subject and its wider > implications. This WG would be remiss if it did not allow a > reasoned, open exchange of views from all sides. I hope we can at > least agree on that. :-) Reasoned debate is welcome, but difficult to conduct when dominated by the extreme views of one individual. This DNSMON/ENUM proposal is well supported, and looks likely to be approved. While the discussion surrounding it might look like a good conduit for you to air your viewpoints, you can't effect the change you desire unless you bring forward your own proposal. These rounds of ceaseless rhetoric are a waste of time because they do not relate to the proposal at hand. Bring *your* proposal, and then we can have *your* discussion With best regards, Andy Davidson From gert at space.net Tue Oct 9 16:39:05 2007 From: gert at space.net (Gert Doering) Date: Tue, 9 Oct 2007 16:39:05 +0200 Subject: [ncc-services-wg] debate and representation In-Reply-To: <68F606BF-D0F6-4FEA-8024-064DD1691A0D@nosignal.org> References: <3678E9F7-3B2E-44EC-83B8-F0A5BAA5845F@rfc1035.com> <68F606BF-D0F6-4FEA-8024-064DD1691A0D@nosignal.org> Message-ID: <20071009143905.GH69215@Space.Net> Hi, On Tue, Oct 09, 2007 at 03:22:12PM +0100, Andy Davidson wrote: > This DNSMON/ENUM proposal is well supported, and looks likely to be > approved. Following the discussion, I see three voices of support and one voice of doubt (plus other voices that go into technicalities without expressing a clear voice in either direction). I'm not sure whether I see this as "well supported". Just because you have a different opinion from Jim doesn't mean his points are invalid or he is doing a bad job as board member. Personally, I can see both sides of the debate, and my suggestion would be "have those that use DNSMON pay a fair price for it" ("those" would be "owners/operators of DNS servers that are monitored"). I do think that the RIPE NCC is uniquely qualified to run the job - due to its proven neutrality and competence - but indeed, there is a certain danger of distorting the market, so this should not be "for free". Gert Doering -- APWG chair, but speaking as "net user" -- Total number of prefixes smaller than registry allocations: 122119 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From jim at rfc1035.com Tue Oct 9 16:40:34 2007 From: jim at rfc1035.com (Jim Reid) Date: Tue, 9 Oct 2007 15:40:34 +0100 Subject: [ncc-services-wg] debate and representation In-Reply-To: <68F606BF-D0F6-4FEA-8024-064DD1691A0D@nosignal.org> References: <3678E9F7-3B2E-44EC-83B8-F0A5BAA5845F@rfc1035.com> <68F606BF-D0F6-4FEA-8024-064DD1691A0D@nosignal.org> Message-ID: <09CC00E1-059E-4481-9D2B-D939FD9E84FA@rfc1035.com> On Oct 9, 2007, at 15:22, Andy Davidson wrote: > It's hard to differentiate between Jim wearing his jewel encrusted > NCC board crown and Jim wearing his tasteful Lochcarron beret tam I have already stated that if I am ever speaking as a board member or on behalf of the board, that would be made perfectly clear. I am happy to repeat that. > can you really offer a truly impartial viewpoint on a matter which > has caused you both personal and professional angst, and in which > you have an NCC board interest ? Yes. I work as a freelance consultant. So I have plenty of practice at putting my personal and professional feelings to one side in order to act in the best interests of my clients. I use those skills on the boards that I serve. From that perspective, the NCC is just another client. Can I suggest that if you want to continue this discussion, we do so in private? This is no longer appropriate for the list. From andy at nosignal.org Tue Oct 9 16:57:47 2007 From: andy at nosignal.org (Andy Davidson) Date: Tue, 9 Oct 2007 15:57:47 +0100 Subject: [ncc-services-wg] debate and representation In-Reply-To: <09CC00E1-059E-4481-9D2B-D939FD9E84FA@rfc1035.com> References: <3678E9F7-3B2E-44EC-83B8-F0A5BAA5845F@rfc1035.com> <68F606BF-D0F6-4FEA-8024-064DD1691A0D@nosignal.org> <09CC00E1-059E-4481-9D2B-D939FD9E84FA@rfc1035.com> Message-ID: On 9 Oct 2007, at 15:40, Jim Reid wrote: > Can I suggest that if you want to continue this discussion, we do > so in private? This is no longer appropriate for the list. Jim - I am happy to talk to you in private, and I agree we have strayed offtopic. As I see it, there remains one pertinent issue at hand :- I support Ondrej Sury's proposal, "Allow DNSMON services to monitor ENUM domains". As for Jim's concerns - I will wait for him to submit his proposal. Regards, Andy Davidson. From jim at rfc1035.com Tue Oct 9 17:35:21 2007 From: jim at rfc1035.com (Jim Reid) Date: Tue, 9 Oct 2007 16:35:21 +0100 Subject: [ncc-services-wg] Commercial DNS monitoring services at the NCC In-Reply-To: References: <3678E9F7-3B2E-44EC-83B8-F0A5BAA5845F@rfc1035.com> <68F606BF-D0F6-4FEA-8024-064DD1691A0D@nosignal.org> <09CC00E1-059E-4481-9D2B-D939FD9E84FA@rfc1035.com> Message-ID: <2FD98002-3FAA-4497-9632-B13DF6270413@rfc1035.com> On Oct 9, 2007, at 15:57, Andy Davidson wrote: > As for Jim's concerns - I will wait for him to submit his proposal. I thought I already had... :-) Here it is again, perhaps more explicitly than before. There a number of other organisations who are monitoring DNS servers, some of whom may be willing to offer this as a commercial service. IMO those advocating the NCC is the only provider of DNS monitoring servers should demonstrate that that is the case, or that alternative offerings are tainted in some way and cannot be as impartial as the NCC's would be. If there really is no alternative, then the justification for extending the scope of the NCC offering is on stronger foundations. My earlier concerns still stand -- unless contradictory evidence emerges. Those concerns would diminish, but not go away, if it does turn out that there is no viable alternative and that fact is clearly documented. From daniel.karrenberg at ripe.net Tue Oct 9 17:47:41 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 9 Oct 2007 17:47:41 +0200 Subject: [ncc-services-wg] (no subject) Message-ID: <20071009154741.GB345@105.255.255.10.in-addr.arpa> Subject Excursion to NSD history. Was: Allow DNSMON services to monitor ENUM domains Reply-To: In-Reply-To: <3678E9F7-3B2E-44EC-83B8-F0A5BAA5845F at rfc1035.com> On 08.10 14:33, Jim Reid wrote: > ... And as a former employee of an LIR who saw their > membership fees being used by the NCC to nurture DNS software that > undermined that company's products. ... Jim, I assume you mean NSD. I'll react to the dnsmon side of this separately. The intention of this message is to put the record straight and voice some opinions on the NSD side. Full disclosure: I am a long standing member of the (European) Internet community and speak as such. But be informed of these other things: My personal view is that the RIPE NCC needs to be much more than a number "factory". I am on record with this view consistently over time and from far before the NCC was actually established. [Ref: RIPE meeting minutes, ripe-019, ...] I am the founding CEO of the RIPE NCC and currently serve as is in the role of Chief Scientist. I am one of the instigators of what became NSD; some have said I am *the* instigator but I feel that is not quite right. The gestation of ideas like this is always very hard to pin down. John Crain, Ted Lindgreen and Alexis Yushin and possibly others instigated as much as I did. Facts: NSD was developed by NLnet Labs http://www.nlnetlabs.nl/ and not the RIPE NCC. When development of NSD started we were not aware of anyone developing something similar, neither proprietary nor open source. If someone had offered a realistic alternative at the time the RIPE NCC would have taken it and I doubt if NLnet labs had undertaken to develop a "me too". Development of NSD was above board from before it started. Both NLnet Labs and RIPE NCC told the community what we were up to; we actively solicited feedback about our plans and received nothing but encouragement and good suggestions. The NCC resources that went into NSD were at the *very most* 3 months of my time. It is very difficult to account for that since I do not work on a single thing at a time; neither do I work 9-5 and creative work does mostly happen outside these hours anyway. I was the only NCC staff involved with the project. I fully participated in the design of NSD 1 as part of my NCC duties. Since NSD 2 my involvment is reduced to very sporadic advice. I developed the DISTEL test lab and performed regression and performance testing of NSD 1 as part of my NCC duties. See http://www.ripe.net/ripe/meetings/ripe-42/presentations/ripe42-dns-distel/index.html After the first versions of NSD 1 were released I have done no furhter work on this. NLnet Labs is operating a test lab now that is built on the foundations of DISTEL. Opinions: The main reason for the creation of NSD were massive concerns that erupted (post 9/11) about the lack of diversity in major widely deployed DNS software. These concerns came from both the technical community but more importantly from layer 9 and above. Those who are not sympathetic to industry self regulation in general and to organisations like ICANN and the RIPE NCC in particular were creating all sorts of FUD in this area with the intention to harm us. Something needed to be done. Any mishaps with the operation of k.root-servers.net are a considerable danger for the RIPE NCC's reputation as a professional organisation, and more importantly in the light of the "Internet Governance" discussions. So hardening this operation is necessary and in the interest of the RIPE NCC. The use NSD has indeed hardened this operation in more than one way. Any performance increase of DNS software on RIPE NCC operated authoritative DNS name servers saves money for additional hardware that would otherwise be required. One could easily defend the level of our involvment in the development of NSD by direct RIPE NCC operational needs: direct involvement in the design made sure that our requirements were met by the product. Thorough regression testing was a prerequisite for us to deploy the software on k.root-servers.net anyway; doing it as part of the NSD effort rather than post-factum product testing was a much more efficient. I believe strongly that the RIPE NCC should help along open source efforts that meet its operational needs and that also meet operational needs of the RIPE community. So even without the very valid defense above it would have been fully appropriate to participate. The NCC should not just be a number factory but also be a place where the membership can place activities that further their common goals and that need a professional and neutral organisation to do them. This is our strength. Letting the RIPE NCC degenerate to a number factory would very likely weaken it to the point where it could be taken over by others, such as governments. We actively communicated to the RIPE community and beyond what we were planning and doing at all times. As far as I remember noone objected at the time. Certainly there were no significant objections from either the RIPE community or the RIPE NCC membership. I find it aggrevating to be critisised about this *long* after the fact when indeed the channels were wide open at the time, as they always are. Daniel From Ian.Meikle at nominet.org.uk Tue Oct 9 17:55:27 2007 From: Ian.Meikle at nominet.org.uk (Ian Meikle) Date: Tue, 9 Oct 2007 16:55:27 +0100 Subject: [ncc-services-wg] Commercial DNS monitoring services at the NCC In-Reply-To: <2FD98002-3FAA-4497-9632-B13DF6270413@rfc1035.com> Message-ID: ncc-services-wg-admin at ripe.net wrote on 09/10/2007 16:35:21: > On Oct 9, 2007, at 15:57, Andy Davidson wrote: > > > As for Jim's concerns - I will wait for him to submit his proposal. > > I thought I already had... :-) > > Here it is again, perhaps more explicitly than before. > > There a number of other organisations who are monitoring DNS servers, > some of whom may be willing to offer this as a commercial service. > IMO those advocating the NCC is the only provider of DNS monitoring > servers should demonstrate that that is the case, or that alternative > offerings are tainted in some way and cannot be as impartial as the > NCC's would be. If there really is no alternative, then the > justification for extending the scope of the NCC offering is on > stronger foundations. My earlier concerns still stand -- unless > contradictory evidence emerges. Those concerns would diminish, but > not go away, if it does turn out that there is no viable alternative > and that fact is clearly documented. I think there is a contradiction here. You say there are organisations that provide this service, but then also say that other organisations are prevented from offering this service because RIPE do. I am not aware of any other services. At the risk of advertising, can you send specific details of alternative services to the list? If you do then I for one will look at them. Ian From daniel.karrenberg at ripe.net Tue Oct 9 18:38:09 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 9 Oct 2007 18:38:09 +0200 Subject: [ncc-services-wg] Excursion to NSD history. Was: Allow DNSMON services to monitor ENUM domains In-Reply-To: <20071009154741.GB345@105.255.255.10.in-addr.arpa> Message-ID: <20071009163809.GC345@105.255.255.10.in-addr.arpa> Olaf Kolkman has just reminded me that he worked on early versions of NSD as part of his duties as a RIPE NCC staffer. In particular Olaf contributed the irst implementation of the zone file compiler. I apologise to Olaf for failing to acknowledge his very valuable contribution and I apologise to all of you for not having this fact 100% right. I do not consider this to change the facts significantly and it does not change the basis for any of the opinions I express. Make your own judgement. Daniel From Niall.oReilly at ucd.ie Tue Oct 9 18:55:04 2007 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Tue, 09 Oct 2007 17:55:04 +0100 Subject: [ncc-services-wg] Commercial DNS monitoring services at the NCC In-Reply-To: <2FD98002-3FAA-4497-9632-B13DF6270413@rfc1035.com> References: <3678E9F7-3B2E-44EC-83B8-F0A5BAA5845F@rfc1035.com> <68F606BF-D0F6-4FEA-8024-064DD1691A0D@nosignal.org> <09CC00E1-059E-4481-9D2B-D939FD9E84FA@rfc1035.com> <2FD98002-3FAA-4497-9632-B13DF6270413@rfc1035.com> Message-ID: On 9 Oct 2007, at 16:35, Jim Reid wrote: > IMO those advocating the NCC is the only provider of DNS monitoring > servers should [...] Perhaps I missed something. Is anyone advocating that ? If not, why suggest that they should [...] ? /Niall -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From john.crain at icann.org Tue Oct 9 18:44:10 2007 From: john.crain at icann.org (John Crain) Date: Tue, 9 Oct 2007 09:44:10 -0700 Subject: [ncc-services-wg] Commercial DNS monitoring services at the NCC In-Reply-To: <2FD98002-3FAA-4497-9632-B13DF6270413@rfc1035.com> References: <3678E9F7-3B2E-44EC-83B8-F0A5BAA5845F@rfc1035.com> <68F606BF-D0F6-4FEA-8024-064DD1691A0D@nosignal.org> <09CC00E1-059E-4481-9D2B-D939FD9E84FA@rfc1035.com> <2FD98002-3FAA-4497-9632-B13DF6270413@rfc1035.com> Message-ID: Hi Jim, all I wear too many hats to even remember which is which so I'll just put on my "I operate some DNS stuff hat". Firstly I don't believe that adding e164.arpa zones to the monitoring will make a withdrawal from offering DNSMON services in the future any harder than it is today. The initial proposal is about extending the space monitored. Jim's underlying premise, correct me if I'm wrong Jim, is that the NCC should not be offering the DNSMON service at all. I don't think anyone is advocating that the NCC is the only operator of such a service. I just don't see anyone offering anything remotely close to what DNSMON offers. As a operator DNSMON is "one of" the tools that I use to monitor my systems, I value it as a neutral addition to the pool of tools I have at my disposal. I've always seen DNSMON more as a service to the community rather than to me as operator of one of the servers monitored. RIPE NCC was set up to help enable the collaboration that was RIPE. It did become the RIR and is funded by the NCC members rather than all of RIPE but one of the underlying principles has always been to support the community and to offer services that add value to that community. The check and balance mechanism has always been the membership (and of course the board). If the members believe that this is a valid service for the NCC to offer, or in this case the extension of the service, then so be it. You are correct, there is some risk that operating services like these can distort the market. It is something that during my time at the NCC we were very aware of and I am quite positive that this awareness has not lessened over the years. However without the RIPE NCC taking such projects on, I believe that we would not have things like the Test Traffic Measurement work RIPE NCC did, RIS or DNSMON and that would ,IMHO, be a bad thing. I personally think that at this moment the benefits of DNSMON still outweigh the risks. John Crain On 9 Oct 2007, at 08:35, Jim Reid wrote: > On Oct 9, 2007, at 15:57, Andy Davidson wrote: > >> As for Jim's concerns - I will wait for him to submit his proposal. > > I thought I already had... :-) > > Here it is again, perhaps more explicitly than before. > > There a number of other organisations who are monitoring DNS > servers, some of whom may be willing to offer this as a commercial > service. IMO those advocating the NCC is the only provider of DNS > monitoring servers should demonstrate that that is the case, or that > alternative offerings are tainted in some way and cannot be as > impartial as the NCC's would be. If there really is no alternative, > then the justification for extending the scope of the NCC offering > is on stronger foundations. My earlier concerns still stand -- > unless contradictory evidence emerges. Those concerns would > diminish, but not go away, if it does turn out that there is no > viable alternative and that fact is clearly documented. From daniel.karrenberg at ripe.net Wed Oct 10 10:12:31 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 10 Oct 2007 10:12:31 +0200 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: References: Message-ID: <20071010081231.GA3976@reiftel.local> On 08.10 13:00, Jim Reid wrote: > ... > Besides, whether DNSMON is widely used or not is beside the point. > It's not a core NCC activity. If the NCC spins off DNSMON into an > independent, self-funded entity, that's fine. But when DNSMON is part > of a monopoly RIR and (partly?) funded from that monopoly's > membership fees.... Full disclosure: I am a long standing member of the (European) Internet community and speak as such. But be informed of these other things: My personal view is that the RIPE NCC needs to be much more than a number "factory". I am on record with this view consistently over time and from far before the NCC was actually established. [Ref: RIPE meeting minutes, ripe-019, ...] I am the founding CEO of the RIPE NCC and currently serve it in the role of Chief Scientist. I am the inventor of DNSMON and I implemented most of the first version of it; Marc Santcroos designed and implemented the probing software on the test boxes. Facts: DNSMON is a public service in the sense that we publish the measurements to the world without any reservation. DNSMON serves the RIPE community by providing hard data about the quality and stability of the DNS by a professional, neutral and widely trusted organisation. In particular DNSMON serves the RIPE NCC membership because ISPs tend to depend on a stable DNS for the success of their business. This enables the RIPE members to assure themselves, and those guarding the public interest, that things are in hand. DNSMON serves the TLD operators both by providing a useful operational monitoring service for them, but also by publishing professional, neutral and widely trusted data about TLD DNS service quality. This enables the TLD operators to point to a neutral "audit" of their DNS service quality. Since DNSMON serves both the RIPE NCC membership *and* the TLD operators, both the RIPE NCC membership and the TLD operators fund the operation of the DNSMON service. Both the RIPE community and the RIPE NCC membership agree with this arrangement which was widely discussed and is documented in ripe-271. The operational details on how TLD operators fund the DNSMON service can be found in ripe-342. Opinions: Providing services such as DNSMON positions the RIPE NCC as a professional, neutral and above all *trusted* source of hard data and factual information about the operation of the Internet in our service region and beyond. This is invaluable when it comes to defend industry self regulation, fight inappropriate govenrment regulation and maintain a stable environment in which the Internet can flourish and the businessesof the RIPE membership can be successful. If the RIPE NCC were to reduce itself to a "number factory" this kind of neutrally provided hard data would not be available. It has been pointed out on this list that there are very few organisations that enjoy the level of trust that we have built over more than 15 years. If the RIPE NCC were to reduce itself to a "number factory" it would be much more susceptible to hostile takeover. If the RIPE NCC were to reduce itself to a "number factory" it could not even do this job well, because it would forego the very data that links the "number factory" to the real world. The governance of the RIPE NCC is extremely open, transparent and accessible. As long as this governance process supports what the RIPE NCC is doing, the "monopoly" arguments are irrelevant. Those who provide the funds are fully represented in the RIPE NCC governance and can influence what the RIPE NCC does directly. Others can provide input via RIPE which is always taken very seriously. Divesting RIPE NCC measurement services into a separate organisation is not necessary as long as the RIPE NCC membershp agrees to the RIPE NCC providing those services under the framewaork of ripe-271. This whole discussion is destructive rather than constructive. A need to monitor ENUM "TLDs" is raised. DNSMON exists and can do it. A mechanism for ENUM "TLD" operators to contribute to the funding of the service exists. No other trusted service exists. So unless another trusted service either exists or is about to exist this remains destructive. Daniel From daniel.karrenberg at ripe.net Thu Oct 11 09:20:14 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 11 Oct 2007 09:20:14 +0200 Subject: [ncc-services-wg] Off topic: Excursion to NSD history. In-Reply-To: <20071009163809.GC345@105.255.255.10.in-addr.arpa> References: <20071009154741.GB345@105.255.255.10.in-addr.arpa> <20071009163809.GC345@105.255.255.10.in-addr.arpa> Message-ID: <20071011072014.GH345@105.255.255.10.in-addr.arpa> I got various private questions about NSD history. While it is off topic here is some more for those interestd. Others: ignore. Other Instigators: Jaap Akkerhuis is certainly also one of the instigators. He was with SIDN (.nl) at the time and wanted code iversity too. Jaap contributed quite some ideas in the initial design and continued to comment on requirements and design throghout. Why did the RIPE NCC provide a coder to the project? Well Olaf was not really a coder as such but rather our "Keeper of Requirements". NSDs reason for being is code diversity. This meant that two key requirements were independence of bind and implementing the DNS RFCs. We all woved not to look at bind code at all while this was going on; implementing on the other hand the RFCs was not that easily done: at that time DNS was specified by a lot of separate RFCs, more than a dozen if I remember correctly. And the DNSSEC RFCs were still being (constantly re-) written and yet we anted NSD to be "DNSSEC Ready".;-) Because of his DNSSEC work, Olaf was, and probably still is, one of the greatest living authorities about all things DNS standard. So it was quite logical to make him the editor of our requirements doc. I recall that we often asked specific questions about how this or that response of NSD needed to look like and Olaf would either know the answer right away citing chapter and verse, or dive into a number of interrelated standards and provide us with his interpretation of the gospel. This was invaluable to the project. I do not beleive in the myth that requirements, specification and implementation ever happen in strictly that order in any (successful) software project; I do not think any of the NSD team beleived in that. We did not need specs because the team was small and we did not really farm out stuff to independent groups. So we needed solid requirements to work to and we also needed them to document exactly what NSD does; after all this was a new product intended for critical applications. In order to make that requirement document solid and to test feasibility of some design decisions early on, I asked Olaf to turn the reuqirements into a prototype (perl) implementation of the zone compiler. In the nsd design this piece encodes the vast majority of the requirements but is not critical to query answering performance. So there was a chance that this prototype would actually make its way to production, but the main purpose was to test, refine and clarify the requirements. In the end I believe that the perl zonec did not even ship with NSD. So Olaf's coding work was really a part of his role as "Keeper of Requirements"; a very important role in the project. This was also a role that the RIPE NCC was extremely interested in because we were planning to be one of the first users of NSD for very critical applications. I can hardly imagine a better role for us to take than to actually maintain the requirements for such a critical product during the design and implementation phase. When NSD shipped we really knew that what it was supposed to do met *our*, the NCC's, requirements. We also knew that it did what it was supposed to do since we provided the testing. Synergy! Eough recollection. I Hope I answered the questions that one of you asked and that some of you may have had. Daniel From denis at ripe.net Thu Oct 11 17:18:25 2007 From: denis at ripe.net (Denis Walker) Date: Thu, 11 Oct 2007 17:18:25 +0200 Subject: [ncc-services-wg] New RIPE Database document Message-ID: <470E3EC1.1090601@ripe.net> [Apologies for duplicates] Dear Colleagues, During the Database Working Group (DB WG) session at RIPE 54, it was decided to review the status of those RIPE Documents relating to the RIPE Database. Following discussion on the DB WG Mailing List, a proposal to address this issue was produced, which can be viewed at: http://ripe.net/ripe/maillists/archives/db-wg/2007/msg00162.html No concerns were raised and this proposal has now been implemented. This implementation has resulted in a new RIPE Document, ripe-419 "RIPE Database Reference Manual". This provides a brief introduction to the RIPE Database and references the new RIPE Database Document Library, which can be viewed at: http://www.ripe.net/db/docs.html This library references all the available documents concerning the RIPE Database and associated services. These documents will, in future, be kept up-to-date with all changes to database software and procedures. If you have any questions or concerns, please send an e-mail to . Regards Denis Walker RIPE NCC From ruben at ripe.net Thu Oct 11 16:17:56 2007 From: ruben at ripe.net (Ruben van Staveren) Date: Thu, 11 Oct 2007 16:17:56 +0200 Subject: [ncc-services-wg] Announcing new RIS de-bogon prefixes Message-ID: [Apologies for duplicate messages] Dear Colleagues As part of our effort to de-bogonise new address blocks, we are now announcing prefixes from 186.127.248/21 and 186.128/16 on RRC03. Kind regards, Ruben van Staveren, RIPE NCC -- Ruben van Staveren RIPE Network Coordination Center Information Services Singel 258 Amsterdam NL http://www.ripe.net +31 20 535 4444 PGP finger print 6501 4389 A675 477E DCE5 53D8 9108 49E2 DAFC 271B -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From ondrej.sury at nic.cz Fri Oct 12 17:56:15 2007 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Fri, 12 Oct 2007 17:56:15 +0200 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: References: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> <1191835789.14876.21.camel@yuna> Message-ID: <1192204575.11479.70.camel@yuna> Jim Reid p??e v Po 08. 10. 2007 v 12:14 +0100: > On Oct 8, 2007, at 10:29, Ond?ej Sur? wrote: > > > I understand your concerns in Issue 1-3, but it seems to me, that you > > are arguing with DNSMON service itself and not with my proposal > > which is > > meant to broaden scope of DNSMON service. > > That's absolutely correct Ond?ej. However the two things are linked. > It will be harder and more expensive for the NCC to exit the DNS > monitoring business Here I don't agree with you. How does adding some ENUM domains make it harder than adding more TLD domains? Anyway: 3.4.e164.arpa (AT), 1.3.e164.arpa (NL) and 0.2.4.e164.arpa (CZ) is already monitored by DNSMON. So in a way my proposal just formalizes current state of things. > as it will surely have to do eventually -- if > the DNSMON service has strayed even further from its initial purpose. > Which, IIRC, was to monitor the NCC's own DNS infrastructure. > > Can you please clarify what do you mean by "at the request of the > > Administration concerned"? Who is Administration? Tier-1 operator? > > I was deliberately vague here. :-) It could be the Tier-1 operator. > Or it might be the government/regulator. It depends on the national > circumstances. .e164.arpa is a National Resource, just like a > country's territory and air space. Nobody should be poking around in > .e164.arpa without proper authority. Just like we usually have to > show passports when crossing borders. Ok, understood (probably :-)). 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 at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From daniel.karrenberg at ripe.net Tue Oct 16 16:08:54 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 16 Oct 2007 16:08:54 +0200 Subject: [ncc-services-wg] Re: Allow DNSMON services to monitor ENUM domains In-Reply-To: References: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> <1191835789.14876.21.camel@yuna> Message-ID: <20071016140854.GH17859@reiftel.karrenberg.net> On 08.10 12:14, Jim Reid wrote: > ... > I was deliberately vague here. :-) It could be the Tier-1 operator. > Or it might be the government/regulator. It depends on the national > circumstances. .e164.arpa is a National Resource, just like a > country's territory and air space. Nobody should be poking around in > .e164.arpa without proper authority. Just like we usually have to > show passports when crossing borders. I have never understood this argument really. The DNS can be viewed as a mechanism to publish information to the Internet at large. Why would it be improper to query the published information as long as such querying does not degrade the service, e.g. constitute a DoS attack? So imagine the following hypothetical future situation: ENUM is widely used in -say- Germany and hence the DNS service of 9.4.in-addr.arpa. has become operationally important to ISPs in the RIPE region; SKYPE is a thing of the past, etc.. Now suddenly customers of ISPs are having difficulties getting their calls connected. A quick analysis suggests that the DNS service for 9.4.in-adr.arpa. is not always reachable. The ISPs ask the RIPE NCC both as RIPE participants and as RIPE NCC members to monitor the quality of this DNS service which is critical to their business. The NCC complies. Next Merkel calls Pawlik and says: "Dear Axel, you are poking around in my people's ENUM servers, please stop that". What should Axel's answer be: 1) "Dear Angela, I am so sorry that I poked into your national assets. It was the members that made me do it; but of course I will stop if you take offense." 2) "Dear Angela, our member's have some problems that may have been caused by data about your national assets not being available as it should be. Our members really have a need to know at any time if this is the reason for their customers complaining to them. Hence we will continue to monitor. By the way: we are generally regarded as a highly professional and neutral source of such operational measurements." I would expect that most of the RIPE NCC members and RIPE participants would choose 2. I am also quite sure that the call would never happen becuase noone publishing something on the Internet really assumes that they can stop it from being accessed and monitored. Otherwise Merkel would have to call Google many times a day. Tounge in-cheeckly your's Daniel From jim at rfc1035.com Tue Oct 16 18:22:24 2007 From: jim at rfc1035.com (Jim Reid) Date: Tue, 16 Oct 2007 17:22:24 +0100 Subject: [ncc-services-wg] querying national infrastructure In-Reply-To: <20071016140854.GH17859@reiftel.karrenberg.net> References: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> <1191835789.14876.21.camel@yuna> <20071016140854.GH17859@reiftel.karrenberg.net> Message-ID: <16662142-595C-44B3-9110-CCD230E4B1AB@rfc1035.com> On Oct 16, 2007, at 15:08, Daniel Karrenberg wrote: > I have never understood this argument really. The DNS can be > viewed as > a mechanism to publish information to the Internet at large. Why > would > it be improper to query the published information as long as such > querying does not degrade the service, e.g. constitute a DoS attack? Daniel, there are many parts of the world that have a very different view of the DNS than you and I have. We both know that the odd query for health checking makes no operational difference. But that's not the issue. Some governments and regulators view their ccTLD (and by implication their ENUM Tier-1) name servers as "theirs". It's nobody else's business how those servers are set up and operated. If the name servers are dead or broken, so be it. Third parties (especially foreign third parties) must not interfere in what these states consider is a National Matter. From ripe-wgs.cs at schiefner.de Wed Oct 17 11:59:12 2007 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 17 Oct 2007 11:59:12 +0200 Subject: [ncc-services-wg] querying national infrastructure In-Reply-To: <16662142-595C-44B3-9110-CCD230E4B1AB@rfc1035.com> References: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> <1191835789.14876.21.camel@yuna> <20071016140854.GH17859@reiftel.karrenberg.net> <16662142-595C-44B3-9110-CCD230E4B1AB@rfc1035.com> Message-ID: <4715DCF0.7050801@schiefner.de> Jim, all - Jim Reid wrote: > Daniel, there are many parts of the world that have a very different > view of the DNS than you and I have. We both know that the odd query for > health checking makes no operational difference. But that's not the > issue. Some governments and regulators view their ccTLD (and by > implication their ENUM Tier-1) name servers as "theirs". It's nobody > else's business how those servers are set up and operated. If the name > servers are dead or broken, so be it. Third parties (especially foreign > third parties) must not interfere in what these states consider is a > National Matter. would your worries really apply here? My understanding so far was that the RIPE NCC would not unilaterally start to monitor ENUM zones, eg. 9.4.e164.arpa. Rather it would only do so at the active and explicit request of the respective ENUM Tier 1 registry - which turns your argument upside-down IMHO. Best, Carsten From jim at rfc1035.com Thu Oct 18 09:50:31 2007 From: jim at rfc1035.com (Jim Reid) Date: Thu, 18 Oct 2007 08:50:31 +0100 Subject: [ncc-services-wg] querying national infrastructure In-Reply-To: <4715DCF0.7050801@schiefner.de> References: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> <1191835789.14876.21.camel@yuna> <20071016140854.GH17859@reiftel.karrenberg.net> <16662142-595C-44B3-9110-CCD230E4B1AB@rfc1035.com> <4715DCF0.7050801@schiefner.de> Message-ID: On Oct 17, 2007, at 10:59, Carsten Schiefner wrote: > My understanding so far was that the RIPE NCC would not > unilaterally start to monitor ENUM zones, eg. 9.4.e164.arpa. I would very much hope that was the case Carsten. But Daniel's recent posting -- which can be paraphrased as "why should anyone care if we send a few DNS queries and publish the results?" -- suggests there is some ambiguity or scope for confusion here. ie To the NCC, it doesn't look like unilateral action. But to the sorts of Administrations I referred to, they would see this as unilateral action and interference in a National Matter. Some clarity is needed here so that everyone knows what the operating conditions are: ie a statement which makes it clear that there are no grounds for these sorts of complaints. > Rather it would only do so at the active and explicit request of > the respective ENUM Tier 1 registry - which turns your argument > upside-down IMHO. Er, it was me who was recommending that any monitoring would only be done at the request of the Administration concerned. For some vague definition of "Administration" which could include the Tier1 registry. BTW, I've parked the wider discussion of DNS monitoring as far as this thread is concerned. My views on that have not softened or changed. Even if I am a lone voice crying in the wilderness. :-) Crying being the operative word... :-) From Niall.oReilly at ucd.ie Thu Oct 18 11:45:57 2007 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 18 Oct 2007 10:45:57 +0100 Subject: [ncc-services-wg] querying national infrastructure In-Reply-To: References: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> <1191835789.14876.21.camel@yuna> <20071016140854.GH17859@reiftel.karrenberg.net> <16662142-595C-44B3-9110-CCD230E4B1AB@rfc1035.com> <4715DCF0.7050801@schiefner.de> Message-ID: On 18 Oct 2007, at 08:50, Jim Reid wrote: > [Carsten Schiefner wrote] >> Rather it would only do so at the active and explicit request of >> the respective ENUM Tier 1 registry - which turns your argument >> upside-down IMHO. > > Er, it was me who was recommending that any monitoring would only > be done at the request of the Administration concerned. For some > vague definition of "Administration" which could include the Tier1 > registry. From all of this discussion, I suggest the following three points as a basis for agreement. (1) Clarity on the "service envelope" for DNSMON is desirable; (2) Tier-1 ENUM zones are eligible for monitoring by DNSMON; (3) A request for DNSMON monitoring of a Tier-1 ENUM zone will be accepted from a "responsible party" ("Administration", Tier-1 operator, National Regulator, ...) relevant to the zone in question. I hope this helps. /Niall -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From Niall.oReilly at ucd.ie Thu Oct 18 11:47:17 2007 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 18 Oct 2007 10:47:17 +0100 Subject: [ncc-services-wg] querying national infrastructure In-Reply-To: References: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> <1191835789.14876.21.camel@yuna> <20071016140854.GH17859@reiftel.karrenberg.net> <16662142-595C-44B3-9110-CCD230E4B1AB@rfc1035.com> <4715DCF0.7050801@schiefner.de> Message-ID: <47BCC27C-C706-4EE6-9AE8-56FB982F6787@ucd.ie> On 18 Oct 2007, at 08:50, Jim Reid wrote: > I would very much hope that was the case Carsten. But Daniel's > recent posting -- which can be paraphrased as "why should anyone > care if we send a few DNS queries and publish the results?" -- > suggests there is some ambiguity or scope for confusion here. As I read Daniel's posting, a more accurate (but still very rough) paraphrase would be "why should anyone care if we send a few DNS queries to look up already published data?" /Niall -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From daniel.karrenberg at ripe.net Thu Oct 18 13:02:20 2007 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 18 Oct 2007 13:02:20 +0200 Subject: [ncc-services-wg] querying national infrastructure In-Reply-To: References: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> <1191835789.14876.21.camel@yuna> <20071016140854.GH17859@reiftel.karrenberg.net> <16662142-595C-44B3-9110-CCD230E4B1AB@rfc1035.com> <4715DCF0.7050801@schiefner.de> Message-ID: <20071018110220.GC407@reiftel.karrenberg.net> On 18.10 10:45, Niall O'Reilly wrote: > On 18 Oct 2007, at 08:50, Jim Reid wrote: > > >[Carsten Schiefner wrote] > >>Rather it would only do so at the active and explicit request of > >>the respective ENUM Tier 1 registry - which turns your argument > >>upside-down IMHO. > > > >Er, it was me who was recommending that any monitoring would only > >be done at the request of the Administration concerned. For some > >vague definition of "Administration" which could include the Tier1 > >registry. > > From all of this discussion, I suggest the following three points as > a > basis for agreement. > > (1) Clarity on the "service envelope" for DNSMON is desirable; > (2) Tier-1 ENUM zones are eligible for monitoring by DNSMON; > (3) A request for DNSMON monitoring of a Tier-1 ENUM zone will > be accepted from a "responsible party" ("Administration", > Tier-1 operator, National Regulator, ...) relevant to the > zone in question. Full disclosure: speaking as ripe citoyen, but also: ncc staffer, inventor of dnsmon, proponent of the NCC as more than a number factory Opinion: This may be all that is needed in practise. However it may be dangerous to limit ourslves this way. As alluded to in my recent attempt at humour: there may very well be a situation where the RIPE community may want a certain service monitored because their customers depend on it. At the same time the service provider may have a strong interest to hide the deficiencies of their service. From the point of the RIPE NCC, which interest should prevail? Fact: In the case of dnsmon, there has indeed been more than one occasion where such deficiencies were quite obvious and the server operators have indeed tried to get us to discontinue monitoring. So far we have stood firm on the side of telling the truth and providing a useful service to the RIPE community and the Internet community at large. In all the cases I can recall the service was improved after a while. In some instances I have been told personally that the monitoring results helped to get the necessary resources allocated. In one case this concerned an important server directly operated by an agency of a nation state. Opinion: So as fas as I am concerned there is a definite benefit for the RIPE community and the RIPE membership in retaining the authority to determine what we monitor. Daniel From ripe-wgs.cs at schiefner.de Thu Oct 18 13:53:45 2007 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Thu, 18 Oct 2007 13:53:45 +0200 Subject: [ncc-services-wg] querying national infrastructure In-Reply-To: References: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> <1191835789.14876.21.camel@yuna> <20071016140854.GH17859@reiftel.karrenberg.net> <16662142-595C-44B3-9110-CCD230E4B1AB@rfc1035.com> <4715DCF0.7050801@schiefner.de> Message-ID: <47174949.1020406@schiefner.de> Hi Jim, Jim Reid wrote: > [...] Some clarity is needed here so that everyone knows > what the operating conditions are: ie a statement which makes it clear > that there are no grounds for these sorts of complaints. I guess such constrains could very well go into the DNSMON policy (RIPE-342). I further believe it is defacto handled already this way for the monitored TLDs. > Er, it was me who was recommending that any monitoring would only be > done at the request of the Administration concerned. For some vague > definition of "Administration" which could include the Tier1 registry. I would only see the Tier 1 registry as the requesting entity as it is supposed to act with the consent of the "Administration" anyways. Best, Carsten From pk at DENIC.DE Thu Oct 18 18:18:48 2007 From: pk at DENIC.DE (Peter Koch) Date: Thu, 18 Oct 2007 18:18:48 +0200 Subject: [ncc-services-wg] querying national infrastructure In-Reply-To: References: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> <1191835789.14876.21.camel@yuna> <20071016140854.GH17859@reiftel.karrenberg.net> <16662142-595C-44B3-9110-CCD230E4B1AB@rfc1035.com> <4715DCF0.7050801@schiefner.de> Message-ID: <20071018161848.GI5305@unknown.office.denic.de> On Thu, Oct 18, 2007 at 10:45:57AM +0100, Niall O'Reilly wrote: > (3) A request for DNSMON monitoring of a Tier-1 ENUM zone will > be accepted from a "responsible party" ("Administration", > Tier-1 operator, National Regulator, ...) relevant to the > zone in question. so this suggests an asymmetric treatment of Tier-1 ENUM zones and TLDs? -Peter From Niall.oReilly at ucd.ie Thu Oct 18 21:30:10 2007 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 18 Oct 2007 20:30:10 +0100 Subject: [ncc-services-wg] querying national infrastructure In-Reply-To: <20071018161848.GI5305@unknown.office.denic.de> References: <2413863B-F9BE-4430-BEAF-47EAD4F57F4E@rfc1035.com> <1191835789.14876.21.camel@yuna> <20071016140854.GH17859@reiftel.karrenberg.net> <16662142-595C-44B3-9110-CCD230E4B1AB@rfc1035.com> <4715DCF0.7050801@schiefner.de> <20071018161848.GI5305@unknown.office.denic.de> Message-ID: On 18 Oct 2007, at 17:18, Peter Koch wrote: > so this suggests an asymmetric treatment of Tier-1 ENUM zones and > TLDs? You may be right; I'm not sure. If so, is it a problem, as long as we have clarity? /Niall -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From agm at ripe.net Tue Oct 23 14:45:13 2007 From: agm at ripe.net (Axel Pawlik) Date: Tue, 23 Oct 2007 14:45:13 +0200 Subject: [ncc-services-wg] RIPE NCC General Meeting October 2007 - Final Reminder to Register Message-ID: <471DECD9.7070100@ripe.net> [Apologies for duplicate e-mails] Dear RIPE NCC member, The RIPE NCC Executive Board is pleased to invite you to the RIPE NCC General Meeting (GM). The meeting will be held at 17:45 on Wednesday, 24 October 2007 during the RIPE 55 meeting in Amsterdam, the Netherlands. You can register online at: https://lirportal.ripe.net/lirportal/meeting/registration-general/meeting.html?id=48 You will also be able to register at the GM registration desk until 15:00 on Wednesday, 24 October 2006. After this time, registration for the GM will close. Please bring the appropriate identification to the GM registration desk. Once registered you will be given your meeting folder (containing your membership status and details of your voting rights) and your GM badge. More information on the GM can be found at: http://www.ripe.net/membership/gm/gm-october2007/ The GM agenda is available at: http://www.ripe.net/membership/gm/gm-october2007/agenda.html The GM supporting documents can be downloaded at: http://www.ripe.net/ripe/draft-documents/gm-october2007/ If you have any questions about the GM, please e-mail us at: agm at ripe.net Regards, Axel Pawlik Managing Director RIPE NCC