From: Bruce Tonkin Sent: Thursday, 4 October 2001 11:47 PM To: 'jo.lim@auda.org.au' Subject: Response to Registry Technical Specification - THIS TIME AFTER A SPELL-CHECKER To: Jo Lim Chief Policy Officer .au Domain Administration Ltd Melbourne IT response on the draft registry technical specification ******************************************************************* ******************************************************************* Executive Summary ***************** The Registry Technical Specification is a significant document that will define both the performance levels of the new registry operators within ".au" (which have a significant impact on the level of customer service that a registrar can provide a registrant), and the mechanisms for communication between a registry operator and registrars. Following the release of the Competition Model for the ".au" Domain Space report in June 2001 by the auDA Competition Model Advisory Panel, and its subsequent acceptance in full by the auDA Board, we had expected (consistent with section 2.3.13 of the report) to be involved at an early stage in the development of the detailed registry technical specification using an open and transparent Advisory Panel process described in http://www.auda.org.au/panel.html. We are dismayed that auDA has chosen one organisation to operate on its own to produce such an important document, and then left it so late in the process to receive public input. Given auDA's aggressive timetable to introduce the new model of competition by 1 January 2002, it is essential that auDA work more closely with the industry it was partly set up to serve to achieve that aim. The process of developing the registry technical specification has resulted in an unbalanced specification. On the one hand there is a completely new registry/registrar protocol that is untested, and without the input of members of the domain name industry with extensive operational experience in this area. New technical protocols for use by many Internet companies are generally developed over the course of 1 or 2 years, with extensive public participation. On the other hand there is a very comprehensive section on Security Architecture that has benefited from the Australian and international standards in this area, which in turn are a result of extensive industry operational experience in the security area. Melbourne IT recommends that auDA stick with the recommendations of the Competition Model Advisory Panel (see section 2.3.28 of the report, and see section 1.2 and section 2.3 of Attachment C: Technical Requirements for Registry and Registrar, section 2.10). Given the global nature of the Internet, the competition panel sought to use international protocols to maximise the competition within ".au" from both local and international domain name companies, as well as make it easier for Australian domain name companies to compete on an international level. To overcome the problems of every top level domain space (e.g ".com",".info" and ".name") and every country code domain space (".ca", ".uk" and ".au") creating its own registry/registrar protocol, a working group was formed last year in the Internet Engineering Task Force (IETF) to develop a new registry/registrar protocol. This working group has had extensive participation from individuals with extensive operational experience in operating domain name registries or domain name registrars, with at least 4 international meetings to refine the protocol. The latest draft of the protocol is in an advanced state with respect to the basic domain name operations of create, renew, modify and delete. The protocol is also easily extensible to cope with differences in structure within each country. Each of the new top level domain registries (".info", ".biz", ".name", and some of the alternative root registries) is implementing a version of this protocol, and making the software available free-of charge to domain name registrars. The protocol is now in operational use as of 1 October 2001 by many domain name registrars around the world. The advantages of such strong support for the new protocol, is that Australian registrars will benefit from open-source implementations of the protocol and the growing amount of training material available for using the protocol. There will be large body of reference material available for auDA accredited registrars by the time that the registry is ready for operation. This new protocol is called EPP. When the competition panel met in Sydney earlier this year there was extensive discussion of the status of the EPP protocol. The view of this meeting was that auDA should use the current draft of the EPP protocol as a starting point for the specification of a local version of this protocol. It was thought that elements of the protocol that were unnecessary in Australia could be left optional, and that some new data objects could be easily defined to meet the needs of the Australian policy environment. In future when the EPP protocol was finalised as an IETF standard, auDA could easily migrate to the new protocol. Unfortunately none of the designers of the protocol recommended in auDA's draft Registry Technical Specification were in attendance at that meeting. The views of the competition panel advisory committee were then reinforced nearly unanimously by members of the industry that attended the public meeting hosted by auDA on 2 October 2001. Melbourne IT recommends that for the purpose of the auDA tender process (and avoid any delays in the tender process), that the registry tender be required to support a registry/registrar protocol based on the current draft of EPP (which is thoroughly documented). In parallel a technical working group could be formed with participation of the authors of the draft Registry Technical Specification, and the members of the domain name industry with operational experience, to refine the EPP protocol for local conditions (an exercise primarily of refining the data objects). This would allow some preliminary work to be done before the successful registry tenderer is announced, and the specification frozen for the development of the initial test registry. This will avoid any delays to the introduction of the new competition model, that may result from launching into a testbed program where the protocol is ill-defined. Again much time could have been saved if auDA had followed the advice and consulted more closely with members of the Competition Model Advisory Panel. Specific comments on the draft Registry Technical Specification follow: **************************************************************************** ************** Section 2.1.3 (c) - the number in parentheses after each field description should be the "maximum" length - not minimum. Section 2.1.6 (a) - the service availability recommended by the Competition Model Advisory Panel for the registry database (which in turn drives changes to the WHOIS service and the Nameserver service) was 99.9% (see Table A in Section 3 of Attachment C: Technical Requirements for Registry and Registrar of the competition panel report). There is no justification given in the draft for making this change, and any chance is inappropriate without referring to the members of the competition model advisory panel. Section 2.2 - Registry Access Protocol ************************************** This section makes the correct statement that domain name registries of ccTLD's have been developed on an ad hoc basis. It then goes on to perpetuate this problem by defining its own ad hoc registry-registrar protocol, instead of leveraging the massive international efforts to produce a new international protocol for registry and registrars. There is also a statement about the more demanding requirements of gTLDs compared to cctlds. Apart from the hardware requirements for supporting large name spaces, the requirements of gTLDs to date have been far less demanding that those for ccTLDs that have extensive policies such as ".au". IN act the new international protocol - EPP - was designed to be extensible to handle the additional requirements of ccTLDs. Section 2.2 provides a table comparing the protocols of different ccTLDs and TLDs. There is no attempt to provide a timeline with these protocols. Most of these protocols were developed before the advent of technical advances such as XML for specifying the format of messages between two entities that facilitates computerized processing. In the early days of registry/registrar protocol development all processing at the registry was done manually (and in some cases still is - e.g ".org.au"), and thus simple unstructured email messages were appropriate. The protocols were also developed when the volumes of domains being registered was under 1000, rather than 100,000's of domains as at present. The principles that are listed as fundamental to selection of the ".au" RAP are all good, and the selection of EPP is compliant with these principles. In fact these principles were taken into account in discussions within the competition model advisory panel when making its recommendations. Section 2.2 concludes with some reasons why the draft Registry Technical Specification does not recommend the EPP protocol. Point (a) is correct but has no affect on whether to use EPP or the new auDA protocol. Point (b) is not entirely consistent with the recommendations of the competition model advisory panel where it is recommended that an independent body give approval in the case of non-objective policy rules (see section 2.3.29, 2.4.3, and 2.4.4 of the report). The competition model advisory panel envisaged that there may need to be a mechanism for authenticating the approval from an independent body (unless the registry performed that function) (see section 2.3.29). Point (c) is a bit strange as the registry is required to perform final integrity checks on domain name registration (see section 2.3.29), and the detailed policies for 2LDs have yet to be finalised. Point (d) states that EPP has not yet been adopted as an industry standard. It is true that EPP is not yet an IETF standard, but it is currently an open specification in the public domain that has been developed by members of the industry and is now in commercial use by multiple registry operators (as of October 2001). Thus EPP could be described as an open industry standard, or de-facto industry standard. It meets many of the requirements to become a full IETF standard, which is often a formality after several years of commercial use. Point (e) states that there is no public domain implementation of EPP currently available. This is no longer true with the release of implementations by the ".info" and ".biz" registry operators, and the growth of public domain implementations being made available on the Internet. Thus Melbourne IT believes that the timing is appropriate for auDA to select the EPP protocol as the basis of the Registry/Registrar protocol in the ".au" environment. In Section 2.2.1, it is stated that auDA will provide a reference implementation of its protocol for use by Registrars and Registry operators. This is a good objective - but could be achieved more cheaply by using the implementations available for EPP, and perhaps putting the effort to modify these implementations to support auDA specific data objects, and creating an implementation of EPP over SMTP transport (current commercial use of EPP is over the TCP transport layer). In Section 2.2.1, it is also stated that "auDA is continually monitoring developments of the IETF". This is a bold statement, when the current auDA staff are not technical specialists, and none of the authors of the draft technical standard have attended any of the international meetings where this protocol has been developed. A more appropriate statement would be that auDA will form a technical working group with industry and consumer participation to track developments in the IETF related to the DNS, and that members of this working group would be expected to attend meetings of the IETF, in the same way that members of auDA staff and Board directors have attended meetings of ICANN. This was the intent of the competition model advisory panel's recommendation in section 2.10 of Attachment C of the competition panel report. This need not be an additional cost to auDA, as it would expected that members of the Australian domain name industry would attend IETF meetings at their own expense. In Section 2.2.2, the draft describes the proposed new auDA registry/registrar protocol called IRRP. The section states that the protocol will be a work in progress, and this seems likely to delay the introduction of competition into ".au". In section 2.2.2.2, it is unclear why there is a mechanism for authenticating registrar messages to the registry, but not a reciprocal mechanism for registrars to authenticate a message from the registry. Both seem equally important. Appendix B describes the action requests available in the protocol. Operational experience in operating registries over the past 5 years, has led to the inclusion of additional commands in the EPP protocol that makes operation of a registry easier. For example, it is normal to include a renew command as well as create (add) commands. This is because it is normal to bill a registrar on receipt of a create or renew command, but not to charge for modification (update) to records during the lifetime of a registration. It is also normal to create a separate check command to check the existence of a record in a registry without returning detailed information on the record. This allows for the registry to optimise the registry hardware to cache domain name availability information, without requiring a check of the core registry database. An analysis of traffic on commercial domain name registries shows that this is the most commonly used command. For example, software designed to assist domain name registrants to select a domain name often creates a series of alternative names and checks the availability of each before presenting to the end user. The domain-enquire command described in the document is a novel feature, but also doesn't take into account the typical use of a domain name check operation. Most checks do not result in the registration of a domain name. An add-domain function, normally does a check availability first, and then adds the domain. There seems to be no use for a separate domain-enquire command that locks the availability of the domain for some period, before an add-domain command is entered. It would be normal to do this in one command (the add-domain function). It is assumed that this command was created to handle the delays associated with checking domain name eligibility information. Again many of these commands are not related to operational experience. When transport layers such as TCP are used, there are some benefits to establishing a session between a registry and registrar where detailed information about the protocol and identity of both ends can be transferred at the beginning of a set of transactions. This can lead to more efficient processing of the subsequent transactions. Again this industry experience has led to the use of the login and logout commands within the EPP protocol. A more detailed discussion of the protocol and refinement of the protocol would require extensive time of both the authors of the protocol and industry participants to refine the protocol to the same level as available for EPP. Thus again there seems to be little point in duplicating the learning curve of the international domain name registrar community through auDA's own testbed period, when we can start from the experiences already learned. Appendix A, defines the formats of data objects used in the protocol. These objects could be defined for use with the EPP protocol if desired (one of the advantages of EPP is its flexibility), however it maybe better to start with the data objects already defined by existing registries (e.g ".info") and refine those. This particularly relates to definitions of the data formats for address and date fields that are consistent with international convention. Examples of improvements that can be made to the data formats are discussed below. The limitations of which fields of a record may be amended by Registrars and why is poorly defined. The choices between mandatory and optional also seem arbitrary in many places. Including a reg-registrar field explicitly in the domain record. Domain records are the primary records used by registries for billing registrars at the time of name creation and renewal. It is common for a registrant to register domain name with multiple registrars depending o the pricing and service available at the time, and also quite common for a registrant to change registrar at the time of renewal of a particular domain name. Often information regarding a registrant (e.g the registrar field of the registrant) can become inconsistent with the information in the domain record. This problem already occurs with inconsistencies between information in Melbourne IT's DNS registry for ".com.au", and auDA's registrant and contact information registry (AUNIC). In the record format for Registrant Records. (i) There is only one field to specify "trading as" names of the Registrant (ii) There is no field to specify the registration number(s) of these "trading as" names (iii) There is no field to specify Trademarks If the Names Panel Final Report's recommendations are implemented, then the current Derivation Rule will be replaced with a "Connection Rule": ============= http://www.auda.org.au/panel/name/papers/finalreport.html#TOC3.4 3.4 Connection between domain name and domain name licence holder Recommendation: There must be a substantial and close connection between the domain name and the domain name licence holder. A connection between the domain name and the domain name licence holder can be demonstrated if the domain name: a. exactly matches the name on which the domain name licence application is based (eg. company name, trade mark, etc); or b. is a name by which the domain name licence holder is widely known (eg. an acronym, abbreviation, nickname or alias) or is otherwise substantially and closely derived from the name on which the domain name licence application is based. ============= The Registrant will need to demonstrate their complicity with the rule somehow. If the Registrant is required to demonstrate that they are eligible then surely they would be required to list the trading name or trademark that the domain is "connected to". Otherwise there's no way that the application could be properly assessed. Therefore, the Registrant would be required to list the trading name or trademark that is the basis of each domain that they register. For Melbourne IT Ltd to be approved for inww.com.au, we would need to list the trading name "INWW". Then to be eligible for internetnamesww.com.au, we would need to list "Internet Names W W". And so on & so forth to demonstrate eligibility for each of our domains. To prove that these trading names actually exist, we would also need to list each of the registration numbers and jurisdiction for those trading names. Given that this field is limited to 200 characters, this is quite problematic. The mandatory requirement to include IP Addresses for Name Servers in domain name records has been found operationally to be deficient. Often the IP addresses are not updated when a nameserver is moved, and quite often a domain name registrant would not even be aware that the IP address of the Nameserver used by their chosen Internet Service Provider has changed. In the majority of cases it is better to let a DNS Nameserver resolve the hostname of a nameserver to the corresponding physical IP address. Name Servers are listed in zone files such as com.au by their host name. The IP Address is only needed when a domain name like "foobar.com.au" is delegated to a Name Server that is inside the domain such as "child-subdomain.foobar.com.au". One approach suggested in an IETF draft (http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-03.txt) is to create a separate hostname record for those hostnames where an explicit IP address is required. Multiple domain name records could point to the same hostname record, where the IP address information is maintained. In the record formats, it seems redundant information to store both a country code along with the full text name of a country. It would be more efficient to just store the 2-digit country code, and allow end user software to display the 2 digit code as a full text name of the country. In the record formats, it is advised to explicitly create an expiry date field - particularly for the domain name record. There is not always an exact relationship between the creation date and the expiry date derived from a length of registration field. Sometimes domain names are transferred to new owners or new registrars, and this can result in fresh periods of registration that do not line up with the original creation date. In the domain record it would be appropriate to create a domain name status field to indicate the status of the domain (e.g expired, on-hold, suspended, transfer pending etc). See http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-03.txt for examples of status fields on a domain. Again the above list of comments on the record formats is not intended to be exhaustive, and it is highly recommended that auDA start with the formats of records already defined for operational registries with EPP and refine those for Australia. This again avoids the inevitable delays while the registry and registrars learn the appropriate record formats from experience. Section 2.3 - Authoritative Nameserver service ********************************************** Section 2.3.1 - the competition model advisory panel recommended in section 2.4 of Attachment C of the advisory panels report, that it is desirable that these nameservers be located in geographically diverse locations, including US and Europe. The draft technical specification states that secondary nameservers be operated in at least two Australian cities. Again no reason is given for deviating from the advisory panel report. Given that ".com.au" domain names are accessed by people all over the world, it would be appropriate for ensuring that the geographical diversity required in RFC2182 was at least on a global scale rather than just within Australia (thus the exact locations of the overseas servers can be left open). It should be noted that the current geographical diversity of the ".au" nameservers are global. Section 2.4.4 - this section goes into some detail on the types of searches to be available via WHOIS. It is conventional to define a minimum set of searches that must be provided as a free public service (for example an exact match search on a domain name record). Additional types of searchers can then be left open for proposals as part of the tender service. If a more extensive set of searches is required for free, this raises the cost of providing the WHOIS service, and will result in higher costs for domain name registrants who are effectively subsidising the advanced searching services used by a few. It is often better to allow the registry operator to charge for more advanced searching with the charges made public during the tender process and any changes to charges to be reviewed by auDA. Section 2.4.6 - Part (f) defines limits for WHOIS searches. These limits may be appropriate for end users that individually use the WHOIS service, but auDA accredited registrars would require higher transaction rates - particularly if they provide a web front end for their customers or resellers to use that sends WHOIS queries to the registry operator. Section 2.6 (e) - it would be appropriate to set a time limit (e.g 6 months) for when the registry operator must produce an interface consistent with an IETF standard protocol. Section 3 - Security Architecture ********************************** This is an extensive section that draws on operational experience built up over many years and the Australian and International standards in the security area. It would have been good to see section 2 in an equivalent level of detail for the EPP protocol. Given the rigorous detail required in a tender response for this section, it would be advisable for auDA to allow sufficient time for such a detailed response. Section 4 - Business Continuity Plan ************************************ The continuity planning section refers to timeframes in "business days" and excludes Saturday and Sunday in the setting of performance targets. Given that the Internet is used 24 hours by 7 days per week, it would be more appropriate to talk about "days" meaning any of the seven days of the week. Thus the aim should be to re-establish operation of the production level of the registry within 24 hours. Section 5 - Data Escrow Requirements ************************************ In the discussion of the escrow system, it is important that the site nominated by auDA as the escrow site is subject to the same security requirements as Section 3 of the draft specification to ensure that the security of confidential commercial information is maintained. Section 5.2 should also include the requirement to provide a copy of executable code. The licence to auDA to run the Registry software of the Registry operator should be limited in time (e.g 3 months) rather than a perpetual right to use the software. This ensures that auDA is required to put the registry out to tender again in the event of the failure of a registry operator. Section 6 - Domain Name Expiry and Deletion ******************************************** This section discusses requirements for deleting names from the registry. The process for domain name deletion should be more explicit and subject to industry review. For example for a registry to delete a name after it is not renewed the following procedure could apply: (1) Notify the registrar associated with the domain that the domain is past its expiry date (2) After x weeks/days, remove the domain name from the zone file and mark the domain name as suspended in the WHOIS service (this might necessitate a domain name status field in the domain name record - with values such as on hold, transfer pending, deleteprohibited etc) (3) After a further x weeks/days remove the domain name from the registry database (and hence also the WHOIS service) For a registrar to explicitly delete a name on behalf of a registrant, there may be a grace period (e.g 5 days) before the domain is finally deleted from the registry database. During this time the domain would be removed from the zone file and marked as suspended on the WHOIS service. This allows a registrar or registrant to correct an error. In the section on undesirable practices, it is not clear how a registry operator could control these undesirable practices. It would be expected that auDA would take action against a registry operator or registrar that violated these principles. Section 7 - Reporting Requirements ********************************** In part (b) it would also be useful for the registry to report on the number of domain name renewals and deletions during each month. In part (f) the report should provide a table with "the number of" daily database transactions - rather than list every transaction. To conclude, I would like to commend the authors of the Registry Technical Specification on their effort to provide a comprehensive draft. The comments and recommendations above are intended to be constructive, and also reference the work of the competition model advisory panel wherever possible. Melbourne IT will continue to provide any assistance it can to the authors of the specification to ensure the development of a stable and high quality domain name system in Australia. We hope in future that the industry and consumers could be involved at an earlier stage in the production of such documents to avoid wasted effort and assist in obtaining the best result possible. This would also allow more time for public comment. Dr Bruce Tonkin Chief Technology Officer Melbourne IT