ARI Registry Services Operational Comments on the Draft New gTLD Registry Agreement

[Yasmin Omer <Yasmin.Omer@xxxxxxxxxxxxxxx>]

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.