<<<
Chronological Index
>>> <<<
Thread Index
>>>
ARI Registry Services Operational Comments on the Draft New gTLD Registry Agreement
- To: "comments-base-agreement-05feb13@xxxxxxxxx" <comments-base-agreement-05feb13@xxxxxxxxx>
- Subject: ARI Registry Services Operational Comments on the Draft New gTLD Registry Agreement
- From: Yasmin Omer <Yasmin.Omer@xxxxxxxxxxxxxxx>
- Date: Wed, 27 Feb 2013 10:53:28 +1100
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.
![PNG image](pngjYGXnaWKjh.png)
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|