Melbourne IT comments on the .net criteria
Melbourne IT comments on the .net criteria submitted to the GNSO Council 9 July 2004 ======================================================================== ============= ======================================================================== ============== Clarification ============= These comments are submitted by Bruce Tonkin in his role as Chief Technology Officer of Melbourne IT, and are the views from a single registrar. Declaration of Conflict of Interest =================================== Melbourne IT is a 10% shareholder in Neulevel, the operator of the .biz registry. (0) Executive summary ===================== This is a brief summary of the suggested changes to the criteria described in detail below. - recommend the .net subcommittee reference its particular recommendations against the mission and core values of ICANN as listed in the bylaws. - recommend the .net subcommittee consider and include a reference to the criteria used in the first round of new TLDs: http://www.icann.org/tlds/tld-criteria-15aug00.htm - provide tighter minimum criteria for performance specifications for the .net registry. Use the definitions of the .biz agreement as a guide, and also review the actual performance of the .net registry operator averaged over the past 12 months as detailed in the public monthly reports as a benchmark. The objective should be to enhance the current service. The current criteria in the .net registry agreement are well below that acceptable for a registrar. Melbourne IT would prefer to see a reliability figure of 99.95% for the registry/registrar provisioning system. - add "migration strategy" as a selection criteria. The objective should be to minimise the overall .net service cost for existing registrars (ie the migration cost should be outweighed by savings elsewhere), and also maximise the choice available for registrars (e.g choice of thin versus thick registry on a per registrar basis). - remove "maximisation of consumer choice" as a criteria. This is meaningless, as .net is already available to consumers. ICANN is exercising its choice in a competitive registry operator market to choose a registry operator for .net that best meets the needs of its registrar customers. - add a new criteria: "maximise the service provided to registrars". Registrars have no individual choice of registry operator. The service a registrar can provide to a consumer or reseller, will ultimately be determined by the quality and level of service provided by the monopoly .net registry operator. If a registry operator can lower a registrars costs through new and improved services, this will be able to passed onto consumers in the competitive registrar market. - remove the section on "pricing". Pricing is a term best used in the context of consumers, and the price a consumer pays is determined by registrars or their resellers. - add a new criteria "impact on registrar cost". Registrar cost is defined as the impact on a registrar's costs of the .net registry service. The cost consists of migration costs, the registry fees charged to the registrar, ICANN's fee, and may be influenced by any cost savings possible from improved registry service. Applicants should describe how their proposal would reduce a registrars overall costs." - request ICANN to review the registry licence fee for .net, and include it as a condition of the tender. An increase in the .net registry operator fee may allow a reduction in the fees paid to ICANN by registrars, and potentially may lead to a reduction in the retail prices paid by consumers. - under the innovation and value criteria, require applicants to specifically describe how they will enhance three main services: registrar transfers, WHOIS, and allocation of deleted names. These three areas have been the most discussed issues in the GNSO over the past several years, and the tender process is an opportunity for ICANN to seek, on behalf of registrars, innovative solutions that provide a benefit for registrars and their customers. These three areas are significant contributors to registrars costs. - generalize the relative criteria to improve the existing stability, reliability, and security of the registry. Applicants should indicate how their proposed solution compares against the current service as reporting in the current .net operator's monthly reports over the past 12 months, and indicate how they could enhance the service. For example an applicant should provide the mean time to resolution for additions or changes to the .net zone file. - improve the wording regarding suppliers and vendors to avoid the impression that this is targeted at registry operators as suppliers. Here is some suggested wording: "Applicants should indicate how they will implement the registry solution to maximise stability, security and reliability. It is preferable for the .net registry operator to use a diversity of computer hardware vendors, software vendors, telecommunications vendors, Internet service providers, and also locate services across a geographically diverse area." (1) General comments ==================== I recommend that the GNSO report specifically reference its recommendations against ICANN's mission and relevant core values. ICANN's basic mission is: "to coordinate, at the overall level, the global Internet's systems of unique identifiers, and in particular to ensure the stable and secure operation of the Internet's unique identifier systems." The core values relevant to the .net tender are: 1. Preserving and enhancing the operational stability, reliability, security, and global interoperability of the Internet. - this is a core requirement 2. Respecting the creativity, innovation, and flow of information made possible by the Internet by limiting ICANN's activities to those matters within ICANN's mission requiring or significantly benefiting from global coordination. - should encourage creativity and innovation 4. Seeking and supporting broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making. - ensure broad participation in deciding on changes in the .net registry operation. 5. Where feasible and appropriate, depending on market mechanisms to promote and sustain a competitive environment. - putting out the operation of the .net registry for tender is itself a market mechanism to get the best result. 6. Introducing and promoting competition in the registration of domain names where practicable and beneficial in the public interest. The GNSO .net subcommitteee may also wish to review aspects of the criteria used in the first round of new TLDs: http://www.icann.org/tlds/tld-criteria-15aug00.htm As a registrar, Melbourne IT is a customer of the .net registry operator. We believe that ICANN is now taking advantage of the competitive registry operator market to operate a tender process to select a registry operator that can provide the best result to its customers (registrars), and also ensure that the new registry operator ENHANCES the operational stability, reliability, security, and global interoperability of .net in accordance with ICANN's mission. As the .net registry operator is in a monopoly position with respect to .net, it is necessary for ICANN to operate the process on behalf of all the registrars, as registrars can't independently select their own registry operator. Melbourne IT would like to see a better service provided as an outcome of the tender process, and thus ICANN needs to properly benchmark the current performance provided by the existing .net operator. (2) Absolute criteria related to stability, security, technical and financial competence ======================================================================== ============== The performance specifications in the current .net registry agreement are below what Melbourne IT would like to receive as a registrar. For example the performance specifications in the .biz agreement are both at a higher standard (e.g 99.9% uptime for the provisioning system) and more specific. A registrar is very dependent on the uptime available from the registry provisioning system. Although a registry may queue transactions when a registry is done, there is a diminished service offered to customers (for example the availability of a name or the success of registration cannot be guaranteed). The current .net agreement allows for 4 hours unplanned outage per month. A review of the current .net registry operator's actual performance for 2003, shows that most months there was zero unplanned outage. To ensure that registrars do not receive a lower level of service from the .net operator in future, I recommend ICANN establish the average performance measured over a 12 month period, and set this as a benchmark to be met in the tender. Remember it is ICANN's responsibility to ENHANCE the current reliability of Internet services. I would like to see a minimum reliability figure of above 99.95% for the registry provisioning systems (excluding planned outages). The growth in collective industry experience and improvements in technology should be reflected in an improvement in the service levels available with .net. There should also be financial penalty clauses to ensure that registrars are compensated when a registry operator fails its service level agreement. This ensures that there is an economic motivation for the registry operator to operate at the highest levels. (3) Migration issues ==================== When a company considers changing supplier, a key component of the consideration is the cost of migration to the new supplier. Any benefits in a lower price of service need to take into account the migration cost. In the case of the recent .org migration, registrars received no benefit in terms of a lower per transaction cost, and they were forced to accept a high migration cost. Thus the .org process actually led to a net increase in expenses for registrars. It is notable that the number of .org names as a proportion of .com names has slightly dropped since the change in registry operator. Ideally as a registrar, I would like to see the new operator continue to support the RRP protocol and thin registry model, as well as offer the option for registrars to migrate to the EPP protocol (especially useful for new registrars entering the market), and the option to elect to operate with a thick registry model. I would recommend that the "migration strategy" be considered a key criteria (under the relative criteria section) in the selection of the new .net operator, and ensure that the cost of migration for existing registrar customers is properly evaluated (perhaps using a subcommittee of registrars that are not associated with any of the tenders). (4) Competition =============== I see little impact on consumer choice with respect to the .net tender. The .net TLD already exists, and consumers already can choose .net over other TLDs. The recent experience with the change in the .org operator, showed that a change in registry operator has almost no influence on the market (ie the proportion of .org names compared to .com names is slightly below (as of the most recent monthly report on the ICANN website) the proportion prior to the change in operator). Once a company is operating a particular TLD, it is in a monopoly position and there is often little incentive to significantly improve the service for registrars (and their customers). The recent focus of the current .net operator has been on finding new services (e.g WLS) for which it can charge registrars, rather than improving the current services (e.g improving the implementation of the transfers function). Instead I see the tender process itself, if run at regular intervals, giving registrars (and ultimately consumers) the best chance of getting an improved service at an improved cost. I recommend removing the "maximisation of consumer choice" as one of the criteria. It would be better to say: "maximise the service provided to registrars". Registrars have no choice of .net registry operator, but ICANN does have the opportunity as part of the tender process to choose the operator most likely to provide better service. (5) Pricing =========== The prices charged to consumers are determined by registrars and their resellers. The monopoly cost components of a registrars price for .net names, consist of the fees charged by the .net registry operator, and the fee charged by ICANN. Every year ICANN has increased the fees charged to registrars, but has not increased the fees charged to registry operators. Even if ICANN did increase the registry operator fee, the registry operator has a contractual right to pass on this increase to registrars. As the market has grown the monopoly registry operators (which have not lowered their registrar fees in proportion to the growth in domain name volumes) have benefited far more than the registrars (that have generally lowered their prices in an increasingly competitive market). I would like to see ICANN establish as part of the tender process an increase in the fee paid by the registry operator to ICANN for the .net registry licence. Thus ICANN could reduce the fees it charges registrars. The registry operator would need to announce the service fee it will charge registrars, and this may have a net effect of a lower overall cost to registrars. Note that a registry operator should not be constrained in the model it proposes to charge registrars (e.g a registry operator could reduce the costs of registration to encourage growth in the market, or charge for other transactions such as creating name server records). The other cost considerations that are relevant to a registrar, are the cost of migration to a new .net operator, and also the cost savings possible through improved registry services. The three main areas where a registry operator could potentially decrease registrar costs are: - transfers (currently a customer service nightmare) - WHOIS (registrars are being requested to improve accuracy at their cost - potentially a registry could provide services in this area) - Deleted names (the current mechanisms for obtaining desirable recently deleted domain names are inefficient and ultimately expensive for the consumer) The current criteria under the heading "pricing" in the GNSO criteria is too narrow, and implies that this narrow criteria should be considered above other criteria which all have a bearing on cost. The word "pricing" is often confused with the price paid by consumers. Thus I recommend that the section on "pricing" be restated as: "- registrar cost. Registrar cost is defined as the impact on a registrar's costs of the .net registry service. The cost consists of migration costs, the registry fees to the registrar, ICANN's fee, and may be influenced by any cost savings possible from improved registry service. Applicants should describe how their proposal would reduce a registrars overall costs." (6) Innovation and value ======================== The service areas that have attracted the most policy development time in the GNSO in the past few years are: - transfers - WHOIS - delete processes I recommend that the GNSO specifically include these three areas in the criteria related to innovation and value. Each applicant should be required to explain how they would improve the services offered to registrars (and hence ultimately to consumers) in these three areas. The current .net operator has not implemented any improvements in the transfer process. There is a new transfers policy, but it has not been implemented by ICANN or registry operators. Areas where a registry operator could improve service are: authentication techniques (such as the EPP auth-code), dispute resolution processes (establishing a dispute resolution process between registrars and agreeing to implement the outcome of the dispute resolution), transfer undo processes (ensure that a transfer made in error can be completely rolled back). With respect to WHOIS, there are issues associated with data mining and accuracy. A registry operator could propose solutions to improve the WHOIS service in both of these areas. For example, a registry operator could run scans on registrar addresses (with the consent of the registrar) to identify addresses that do not seem real (e.g a street, suburb or country that does not seem to match). Obtaining address information on a global basis is expensive - and very expensive if each registrar is required to obtain such databases. A registry operator could make a significant contribution by obtaining address information for at least part of the world. This information would not stop a registrant from deliberately using false information, but may help improve the accuracy of information provided by registrants that supply bad data by mistake. The current process for re-registering deleted names for the .com and .net domain names is very inefficient. The first-come, first-served allocation method has been very effective for registration of new names where there is little contention between registrars for the same name at the same time. With deleted names, several registrars may wish to acquire the name on behalf of their customer. This is done by saturating the registry with as many add requests as possible at the time the name is scheduled to be deleted. As the more requests that are submitted, the higher the chance just one will succeed, some registrars collude with other smaller registrars (as each registrar is given the same number of registry connections regardless of size) to attempt to pool their connections together and share the proceeds from any names acquired (ie they agree not to compete against each other). This then disadvantages a registrar that does not participate in a pool of registrars. The overall cost of this process is high, and these costs are then passed onto the consumer that eventually receives the recently deleted name. Perhaps the best model in these circumstances, where there is contention amongst consumers for a single name, is an auction model. A registry operator may be able to propose an auction model, as part of the tender process. The model could include how the proceeds of an auction could be distributed (e.g between the original registrant, the original registrar, the registry operator, ICANN, and the new registrar). Note the present .net registry operator has proposed the WLS solution, but it is only a partial solution to the problem, and there is also likely to be contention for WLS entries. The .net registry tender is an opportunity for applicants to offer alternative solutions. (7) Relative criteria relating to stability, security, technical and financial competence ======================================================================== ================ The minimum criteria discussed in section (2) above with respect to stability and reliability could be considered to be the basic criteria necessary to be accredited by ICANN to be a TLD operator. With respect to the .net registry tender, ICANN should be giving weight to those applications that ENHANCE the existing stability, reliability and security of the .net service. The current .net operator has published in its public monthly reports its performance, and applicants should be required to state how their service would match or exceed the current service provided as part of the relative criteria. Thus I recommend adding a relative criteria: - applicants should be required to how their proposed solution compares against the current service as reported in the current .net operator's monthly reports over the past 12 months, and indicate how they could enhance the service. The existing point in the criteria related to the zonefile is put one performance measure. It would be better to state this as an example under a more general point. Here is some proposed text: "- applicants should indicate how their proposed solution compares against the current service as reporting current .net operator's monthly reports over the past 12 months, and indicate how they could enhance the service. For example an applicant should provide the mean time to resolution for additions or changes to the .net zone file." With respect to the text about multiple suppliers and vendors. It is not clear whether this is intended to mean that it is preferable for .net to with a different registry operator compared to .com. This would tend to create a bias against one of the existing registry operators. It may be better to restate as follows: "- Applicants should indicate how they will implement the registry solution to maximise stability, security and reliability. It is preferable for operators to use a diversity of computer hardware vendors, software vendors, telecommunications vendors, Internet service providers, and also locate services across a geographically diverse area." Registry operators should also be required to state whether they plan to support IPv6, and their plans for improving the security of the .net registry solution (e.g trials of DNSSEC).