ARI Registry Services - Operational Comments on the Proposed Final New gTLD Registry Agreement

[Yasmin Omer <Yasmin.Omer@xxxxxxxxxxxxxxx>]

ARI Registry Services - Operational Comments on the Proposed Final New gTLD 
Registry Agreement

The following comments are submitted by ARI Registry Services (ARI) in relation 
to the Proposed Final New gTLD Registry Agreement - 29 April 2013 (the 
Agreement). These comments are limited to clauses that have a direct impact on 
the operation of a new gTLD.

Timing of Payment of Registry-Level Fees
ARI commends ICANN’s recognition of the potential of elapsed time between 
execution of the Agreement and delegation of the TLD in section 6.1(a) of the 
Agreement. However, the revisions to this clause assume there are no 
restrictions imposed by ICANN on a Registry Operator’s ability to commence 
operations (commence Sunrise) upon the delegation of its new gTLD. This 
assumption is invalid. The repercussions of the invalidity of this assumption 
must be considered by ICANN.
Recommendation
ARI recommends further revisions to section 6.1(a) of the Agreement such that 
the Registry Operator’s obligation to pay the Registry-Level Fixed Fees begins 
thirty days from the date upon which the new gTLD is delegated in the DNS to 
the Registry Operator.
This obligation must be aligned with the commencement of the Sunrise period 
following provision of thirty days’ notice as mandated by ICANN. As such, the 
first quarterly payment of the Registry-Level Fixed Fee should be prorated 
based on the number of calendar quarter days between thirty days after the 
delegation date and the end of the calendar quarter in which the thirty days 
after the delegation date falls.
Rationale
According to section 2.1 of the Trademark Clearinghouse (TMCH) Rights 
Protection Mechanism (RPM) Requirements, a Registry Operator must provide ICANN 
with its ‘TLD Startup Information’ at least thirty days prior to commencement 
of its Sunrise.
The TLD Startup Information cannot be submitted prior to delegation of the TLD 
into the root zone. Therefore, the earliest possible time a Registry Operator 
can commence its Sunrise period is thirty days following delegation of its new 
gTLD.
Insofar as the revisions to section 6.1a of the Agreement are intended to 
postpone the effectiveness of the Registry-Level Fixed Fees to a point in time 
where the Registry Operator is capable, not hindered by any ICANN restrictions 
or delays, of commencing its Sunrise, the revisions fail to recognise the 
restrictions in the TMCH RPM Requirements document.
Registry Operators must not be obligated to pay Registry-Level Fixed Fees to 
ICANN when they are hindered, through no fault of their own, from generating 
revenue from the new gTLD.

Domain Name Data Escrow Specification
Section 7, Part A of Specification 2 of the Agreement includes the following 
text;
‘Registry Operator will use the draft version available at the time of signing 
this Agreement, if not already an RFC. Once the specification is published as 
an RFC, Registry Operator will implement that specification, no later than 180 
calendar days after such publishing.’
This provision limits the Registry Operator to the draft version available at 
execution of the Agreement and does not allow the Registry Operator to utilise 
a later draft version of the specification that is updated following execution 
of the Agreement.
This is problematic for Registry Operators that manage the infrastructure for 
several TLDs which may launch at various times.
Recommendation
ARI recommends further revisions to section 7, Part A of Specification 2 of the 
Agreement to allow, but not require, the Registry Operator to utilise any draft 
version that is updated following execution of the Agreement but prior the 
publication of a RFC.
Rationale
Registry Operators that manage the infrastructure for several TLDs will 
continually update their systems to comply with the latest draft version of the 
specification as they progressively execute Registry Agreements for their 
numerous TLDs. Updates to registry systems are implemented across all TLDs.
According to this provision (as written) , the registry systems for new gTLDs 
with an earlier Effective Date cannot be updated to comply with the latest 
draft – these new gTLDs are limited to the draft version that was available at 
execution of the Agreement. These Registry Operators should not be prevented 
from taking steps to ensure their TLD complies with the latest standards. There 
is no rationale for preventing Registry Operators from doing so.
Limiting Registry Operators to the draft version available at execution of the 
Agreement is neither practical nor reasonable especially when considered in the 
context of a Registry Operator managing the infrastructure for several TLDs. 
The recommended action grants Registry Operators the flexibility in updating 
their registry systems whilst not requiring them to continually do so until 
necessary – upon publication of the RFC.

Replacement of the WhoIs Protocol
Section 1 of Specification 4 of the Agreement includes the following text;
‘Registry Operator shall implement a new standard supporting access to domain 
name registration data (SAC 051) no later than 135 days after it is requested 
by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, 
as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation 
is commercially reasonable in the context of the overall operation of the 
registry.’
ARI expresses significant concerns regarding this provision with respect to 
both the ambiguity of the term ‘commercially reasonable’ and its ignorance of 
established ICANN policy making processes.
ARI suggests that the requirement to implement a new standard no later than 135 
days after being requested to do so by ICANN is unreasonable and does not fully 
take into account the potential magnitude of the implementation efforts and the 
differing development capacities of Registry Operators.
Recommendation & Rationale
ARI does not believe that the manner in which the requirement to implement a 
new standard is expressed, framed as an obligation on all Registry Operators, 
is consistent with the Roadmap to Implement SAC 051.
Inclusion of an obligation to implement the new standard in the Agreement, 
without a reasonable attempt to highlight what exempts Registry Operators from 
the obligation, does not demonstrate ICANN’s attempt to negotiate the inclusion 
of such provisions in gTLD registry and registrar contracts, and does not 
recognise the initiation of a GNSO PDP with ccNSO, SSAC and ALAC participation 
to implement a new standard. ARI recommends revision of the text in section 1 
of Specification 4 of the Agreement in light of the arguments made above.
With respect to the requirement to implement the new standard no later than 135 
days following a request from ICANN, ARI notes that the Agreement contains 
numerous references to a requirement of 180 days to implement certain standards 
and changes e.g. section 3.1, Part A of Specification 2 includes a requirement 
to implement a RFC 180 days following its publication. ARI recommends that, at 
the very least, the same 180 day period apply to this provision.

100 Names Concept
Deletion of the provision specifying the Registry Operator’s ability to 
register names for the management, operations and purpose of the TLD in section 
1(b) of Specification 9 of the Agreement and the addition of section 3.2 of 
Specification 5 of the Agreement effectively limits the Registry Operator to 
the registration of 100 names necessary for the operation or the promotion of 
the TLD. Doing so significantly, arbitrarily and unjustifiably, limits the 
flexibility of Registry Operators in implementing their business models and 
launch plans.
Recommendation
ARI recommends:

·       Rejection of the proposed revisions to section 3.2 of Specification 5 
and section 1(b) of Specification 9 of the Agreement.

·       Clarification, in section 1(b) of Specification 9, that for domain 
names registered in the Registry Operator’s own right that are reasonably 
necessary for the management, operations and purpose of the TLD;

o   the Registry Operator must act as the Registered Name Holder as that term 
is defined in the then current ICANN RAA;

o   the Registry Operator must activate these names and such activations will 
be considered Transactions for the purposes of Section 6.1 of the Agreement

o   the Registry Operator must either;

                                            i.         register such names 
through an ICANN accredited registrar; or

                                          ii.         self-allocate such names 
and with respect to those names submit to and be responsible to ICANN for 
compliance with ICANN Consensus Policies and obligations set forth in 
Subsections 3.7.7.1 through 3.7.7.12 of the then current RAA (or any other 
replacement clause setting out the terms of the registration between a 
registrar and a registered name holder).

o   the Registry Operator may release these names for registration to another 
person or entity.

Rationale
The roughly 1900 new gTLD applications propose diverse business models and 
launch plans. ARI is opposed to the concept of there being a cap and is 
similarly opposed to the identification of an arbitrary number (that is, 100) 
to represent that cap.
ARI emphasises that no significant consultation with the wider new gTLD 
applicant pool was conducted in identifying this number. This cap assumes a 
level of uniformity with respect to new gTLD business models and unjustifiably 
attempts to standardize these models at the cost of innovation. Any assertion 
that new gTLD applicants can collectively identify a cap is both redundant and 
not cognizant of the diversity of new gTLD business models – diversity 
reflective of the level of innovation set to take over this industry and 
something that should be encouraged by the new gTLD program.
ARI recognises that ICANN may have concerns regarding the registration of 
domain names by Registry Operators beyond the intended scope of names necessary 
for the management, operations and purpose of the TLD. ARI expects such 
behaviour by the Registry Operator to be subject to Contractual Compliance 
oversight.


Registry Operator Monthly Reporting
ARI has identified the following concerns with respect to Specification 3 – 
Format and Content for Registry Operator Monthly Reporting. Recommendations are 
provided for each concern identified.
Registrar State Columns
When considering a shared registry platform, access to OTE for a registrar does 
not signify any state for a specific TLD, thus the requirement to report 
“ramp-up-registrars” is meaningless and confusing. There is a sequence 
challenge with the “pre-ramp-up-registrars” column. If one takes this status as 
being naturally before the “ramp-up” state, then it might be possible for a 
registrar to have access to OTE, yet only be in the pre-ramp-up state if they 
asked for access to a production TLD, but have not yet received it.
ARI recommends the registrar state columns be removed. The AROS solution should 
provide this information in a more relevant and TLD specific manner and should 
be used instead. To avoid unnecessary changes to the format, it would be 
acceptable for Registry Operators to be allowed to simply to put “0” in the 
“pre-ramp-up and “ramp-up” columns.
‘zfa-passwords’ Column
If a Registry Operator opts to use the CZDA to deliver the zone file, there is 
currently no way to determine this value for the report.
ARI recommends that ICANN obtain the relevant information from the CZDA and as 
a result recommends removal of the column from the report. To avoid unnecessary 
changes to the format, it would be acceptable for Registry Operators to be to 
be allowed simply to put “0” in the “zfa-passwords” column.
‘total-nameserver’s Column
The source data for this report column is ambiguous. Host objects are 
registered, and those host objects act as name servers.
ARI questions whether this column refers to the ‘number of host objects under 
sponsorship’, the ‘number of host objects under sponsorship that are acting as 
name servers’, or ‘the number of name server associations from domains under 
sponsorship’?
ARI recommends that ICANN revise the description of the total-nameservers 
column to clarify the intent of the report column. ICANN should note that host 
objects may be shared across several TLDs on a shared registry platform; 
depending on the requirements, attributing a host object to a TLD may not be 
possible and therefore the provisions added for the Registry Functions Activity 
Report may also apply.


Zone File Access
The addition of the text “optionally through the CZDA provider” throughout 
Section 2 of Specification 4 in no way addresses the ambiguity regarding the 
obligations of the Registry Operator in relation to Zone File Access. While ARI 
expects the nature of this obligation to include ensuring AXFR access to the 
CZDA’s nominated servers once per day per zone, ARI requests documentation of 
the interface between Registry Operators and the CZDA.
Documentation of this interface is consistent with the level of detail provided 
in other Specifications of the Agreement. ARI recommends the following text 
form the basis of ICANN’s efforts to document this interface;

·       In the instance that a Registry Operator chooses to use the CZDA to 
deliver zone file services, the Registry Operator will allow the CZDA to 
nominate IP addresses (no less than 2) from which the CZDA will be able to 
initiate a zone transfer (AXFR). To avoid any confusion, a zone transfer in 
this context complies with RFC 5936.
ARI also requests documentation of the mechanism by which the CZDA provider 
informs Registry Operators of the identity of zone file access users to enable 
Registry Operators to reject and/or revoke access of users that violate the 
terms of use.
ARI recommends the following text form the basis of ICANN’s efforts to document 
this mechanism;

·       The details of all zone file access subscribers for a TLD will be sent 
no less than once a month to the Registry Operator via secure means; or

·       The Registry Operator will be given access to a system operated by the 
CZDA to enable the provision of the details of all zone file access subscribers 
for a TLD to the Registry Operator. Such a system must be accessible by secure 
automated means (no captcha or similar automation prevention systems).

Regards,

[cid:8E023C3D-C34B-4B78-955F-C69952869A92]
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.