ARI Registry Services Operational Comments on the Draft New gTLD Registry Agreement
ARI Operational Comments on the Draft New gTLD Registry Agreement Nameserver queries via WhoIs The WhoIs requirements, as described in Specification 4 of the Draft New gTLD Registry Agreement, with respect to queries for nameserver objects (Section 1.6.1) creates ambiguity between matching domain objects and host objects. Queries for the name "NAME.EXAMPLE" may match a domain object, a host object, or both. It is unnecessarily complicated, particularly when you take into account that greater than 99% of WhoIs queries are from those seeking information about domain objects, not host objects. Recommendation The query string described in Specification 4, Section 1.6.1 of the Draft New gTLD Registry Agreement, should be updated to require a keyword for the search of host objects. Suggested text is provided below, preserving the original requirement for those that have committed to their implementation. 1.6.1 Query format: At least one of WhoIs "NS1.EXAMPLE.TLD" and WhoIs "nameserver NS1.EXAMPLE.TLD" for name-based queries, and WhoIs "nameserver (IP Address)" for address-based queries. Rationale Users of the WhoIs service should know if they are querying for domain object information or host object information. As described above, the name "NAME.EXAMPLE" may identify both a domain object and a host object, however Specification 4 of the Draft New gTLD Registry Agreement does not prescribe a mechanism for clients to obtain responses for domain information only. It is our opinion that the current response for WhoIs "example.com", listing three domain names in the response (EXAMPLE.COM.RAFAELYALUFF.COM, EXAMPLE.COM.AU, EXAMPLE.COM), is undesired by consumers. As the mechanism for performing a match on the domain object is undefined, registry operators will provide their own custom mechanisms to allow users to match domain objects only. Custom behaviour reduces interoperability between servers and creates more effort for developers and maintainers of WhoIs client software. In considering the solution, it should be recognised that domain objects are unique across all registries, whereas host objects exist in every registry in which a registrar has created that host. Furthermore, the host object "NS1.NAME.EXAMPLE" may exist in the ".TEST" registry, however not exist in the .EXAMPLE registry. Queries for the host "NS1.NAME.EXAMPLE" would, according to most current WhoIs implementations, be directed to the WhoIs server for the ".EXAMPLE" TLD. Users requiring host object information from another registry would be required to specify the server name of the WhoIs server for that registry. It is anticipated that including a "nameserver" keyword would not be overly problematic to those users. It is also our experience that queries for nameserver information are almost non-existent, indicating that few users may be impacted. It should be noted that the requested query behaviour for host queries is non-standard when compared across many ccTLDs and even gTLDs. The .info registry does not match host names without specifying a "host" keyword, similar to the behavuor of .au, whereas the .eu registry seems to not provide mechanisms for host object queries. Reserved Names Specification 5 of the Draft New gTLD Registry Agreement is inconsistent in the level of detail provided regarding names that are to be reserved at the second level. Recommendation It is recommended that the list of names that are to be reserved at the second level, in accordance with Specification 5, be compiled by ICANN and form part of the New gTLD Agreement or alternatively provide an easily accessible website to locate this information. This list should include any relevant label general rules on how spaces between names or small words such as 'the' are to be treated, for example how should "Congo, The Democratic Republic of The" which appears on the ISO 3166-1 list be treated. We believe the inclusion of this list is consistent with ICANN's previous practice of attaching schedules of reserved names to Registry Agreements. Rationale Specification 5 of the recently published version of the Draft New gTLD Registry Agreement has been updated to include the initial reservation at the second level a number of names relating to the International Olympic Committee; International Red Cross and Red Crescent Movement. Included is a complete list of the names (strings) that fall into this category. Sections 5.2 and 5.3 of Specification 5 of the Draft New gTLD Registry Agreement, refer to country and territory names that are to be reserved according to the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of countries of the World; and the list of United Names member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names respectively. In earlier versions of the Applicant Guidebook URLs were provided to these source documents, but are not included in this most recent version. In order to provide clarity for Registry Operators about the names, which they must initially reserve at the second level it is imperative that ICANN provide a readily accessible list. Names that are reasonably necessary for the management, operations and purpose of the TLD Section 1(b) of Specification 9 of the New gTLD Registry Agreement - the Registry Operator Code of Conduct (ROCOC) states that; 1. In connection with the operation of the registry for the TLD, Registry Operator will not, and will not allow any parent, subsidiary, Affiliate, subcontractor or other related entity, to the extent such party is engaged in the provision of Registry Services with respect to the TLD (each, a "Registry Related Party"), to: b. register domain names in its own right, except for names registered through an ICANN accredited registrar that are reasonably necessary for the management, operations and purpose of the TLD, provided, that Registry Operator may reserve names from registration pursuant to Section 2.6 of the Registry Agreement; ARI requests clarification on the mechanism by which a registry operator may register domain names in its own right in accordance with Section 1(b) of the ROCOC. Such clarification must take into account the following; * The registry operator's need to ensure that desired domain names are secured by the registry operator as opposed to any other registrant; * That the registry operator MUST use an ICANN accredited registrar to register names in its own right in accordance with Section 1(b) of the ROCOC; * In accordance with the ROCOC, a registry operator cannot give a registrar preferential access to the registry system. This raises the question as to how a registry operator can ensure that the registrar it selects to register names in the registry operator's own right is able to register the desired names, such that other registrars are not able to register those names (as the names are required for the operation of the registry) without breaching the ROCOC. Delegation of nameservers to names for promotional purposes Whilst new gTLD registry operators will desire to delegate certain domain names for the purposes of promoting them for registration by eligible third party registrants e.g. banana.fruit, a current literal reading of the ROCOC suggests that doing so would violate Section 1b of that code. ARI Registry Services notes that the primary purpose of the ROCOC is to protect against possible abuses related to registry-registrar cross ownership. Frontrunning, the situation whereby the registry operator is competing with potential registrants to register a domain name and is advantaged in doing so by virtue of it having access to registry data is one possible abuse. The delegation of a domain name by the registry operator for the purposes of promoting the registration of that domain name does not result in the registry operator competing with potential registrants. On the contrary, the domain name will be used to promote it to ALL potential registrants who are eligible, in accordance with the registry's policies, to register a domain name in the TLD. Therefore, whilst the delegation of domain names by the registry operator for promotional purposes may be considered a breach of Section 1(b) of the ROCOC taking a literal interpretation, ARI Registry Services does not believe that it breaches the spirit of the ROCOC. Alternatively, ARI Registry Services contends that simply assigning nameservers to a domain name for the purposes of hosting content that promotes the domain name does not breach the ROCOC. Doing so does not result in a 'registered name' as defined in the 2009 Registrar Accreditation Agreement. In this scenario, the domain name has not been 'taken out of circulation' and is still available for registration by registrants who comply with the registry's policies. As such, WhoIs information for the domain name would clearly indicate that the domain name is available for registration. ARI Registry Services requests that ICANN clarify the manner in which section 1(b) of the ROCOC will be interpreted with respect to; i. the registry operator's delegation of domain names for promotional purposes; ii. the assignment of nameservers to a domain name by the registry operator for the purposes of hosting content that promotes the registration of the domain name; In considering this request, ICANN should avoid any clarification that hinders the registry operator's ability to successfully promote domain names in a competitive market. Zone File Access ARI Registry Services has concerns regarding Zone File Access as described in Specification 4, Section 2 of the Draft New gTLD Registry Agreement. Specifically; * The status and operational readiness of the Centralized Zone Data Access Provider (the "CZDA Provider"); and * The Zone File Access Format; in a letter dated 21 February 2013 to Mr Keith Drazek, Akram Atallah stated that 'we plan to offer in the Centralized Zone file Access System an option for registries to periodically send their zone files in DNS AXFR format. The system will convert the zone file to the format described in the Agreement. Registries that choose this option would not have to do the zone file format conversion.' We request that the option for registries to send their zone files in DNS AXFR format is reflected in Specification 4, Section 2.1.4 of the New gTLD Agreement. Regards, [cid:image001.png@01CE14D5.EC0652B0] YASMIN OMER Policy & Industry Affairs Officer ARI REGISTRY SERVICES Melbourne | Los Angeles P +61 3 9866 3710 E yasmin.omer@xxxxxxxxxxxxxxx<mailto:yasmin.omer@xxxxxxxxxxxxxxx> W www.ariservices.com<http://www.ariservices.com/> ARI Registry Services is an evolution of AusRegistry International. Follow us on Twitter<http://twitter.com/#!/ausregistryint> The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately.