Today, we sent the following response to a public comment period opened by ICANN on the advice it received from its Governmental Advisory Committee (GAC) on new "safeguards" for new gTLDs.
IFFOR’s thoughts and proposed solution to GAC safeguard advice
Produced in response to public comment period "New gTLD Board Committee Consideration of GAC Safeguard Advice" opened on 23 April 2013.
May 14, 2013
We thank you for the opportunity to comment on the safeguard measures for new gTLDs as proposed by the Government Advisory Committee (GAC) in its formal advice from the Beijing meeting. This process demonstrates the strength of the multi-stakeholder model that ICANN uses in reaching final determinations.
IFFOR would like to lend its broad support to GAC's safeguard advice. We find it represents a best-faith effort by the world's governments to identify potential public policy issues within the new gTLD program. Many of the "safeguards" proposed are appropriately drawn, providing clear guidance without being unduly prescriptive.
We do have some specific concerns and considerations, and hope that this is an opportunity for a broader range of minds to work toward a better overall policy package, with the GAC advice acting as a foundation. Since IFFOR prides itself on being a pragmatic organization, wherever possible we propose solutions to the issues identified.
Timing and delays in the new gTLD program
The issues identified are important, well noted, and better on the table now than after new gTLD applicants have been approved and contracts signed.
However, similar inflection points in the past ("overarching issues", and the "GAC Scorecard" to name but two) have led to significant delays in the program.
A further delay is best avoided at this stage, and, we believe not necessary since the process for resolving registry-specific GAC advice has already been developed within ICANN, and with effective resolution.
IFFOR’s baseline policies were created in large measure specifically to handle GAC concerns over the last top-level domain that was approved by ICANN, dot-xxx.
The solution reached over many years of careful deliberation with the GAC, ICANN and registry operator ICM Registry, was that IFFOR would draw up a series of "baseline policies" and that these would be used as the basis for policies that the registry would subsequently introduce.
ICM Registry developed its policies and systems to comply with IFFOR's policies. This process has worked well.
As a result, we believe the same approach can be used to meet GAC concerns for new gTLDs. A policy approach with after-the-fact compliance reviews would answer GAC concerns while providing a flexible process for registry operators. It would also mean unnecessary delay will be avoided, and, crucially, it can take place within a framework that ICANN has already approved and thoroughly tested.
IFFOR is developing a new set of "Safeguard Policies" to meet all six safeguards that the GAC requested for all new gTLDs. We intend to adopt a simple licensing system to make this work readily and easily accessible to all new gTLD applicants.
Such an approach is business friendly since it allows registry operators to move into the operational part of their applications while also accommodating GAC concerns. The alternative is a lengthy, and largely unnecessary, policy debate at the ICANN level.
The safeguards themselves
The six broadest safeguards are, IFFOR feels, appropriate and can be instituted at the registry level without a damaging impact on new gTLD businesses, especially if the industry as a whole adopts them.
Accurate and reliable Whois data has been a growing demand not only from governments but also business and consumer groups. Recent agreement in the new contract for registrars (the RAA) demonstrates that the provision of accurate domain registration data (and systems for indentifying inaccurate data) will soon become accepted industry practice.
The twice-annual check-up proposed by the GAC is possible. In a competitive new gTLD market, registry operators may even find a higher level of Whois accuracy and frequent checks can act as a positive business differentiator.
IFFOR has already drawn up a pragmatic policy and reviewed implementation of a system that is able to achieve the Whois verification (Safeguard 1), Documentation (Safeguard 4), Making and Handling Complaints (Safeguard 5) and Consequences (Safeguard 6) safeguards.
Likewise, Mitigating abusive activity (Safeguard 2) and Security checks (Safeguard 3) are already policies that have been developed by IFFOR, with real-world systems in place, complete with compliance checks and all taking place within the overall ICANN system. The systems can bring positive business benefits.
The GAC advice includes a number of references to "applicable law" that rightly concerns gTLD applicants regarding the implications, especially given the global nature of domain names.
From a purely legal perspective, every registry operator will be based in a jurisdiction with applicable laws that they will be expected to operate under. However, on a global scale and a policy perspective, if a registry operator requires registrants under their top-level domain to agree to a specific set of policies and if the registry incorporates the ability to adopt or require registrants to follow industry best practices, then the tension between a fast-moving Internet world and slower moving national legislatures can be relieved. Essentially, registry best practices exceed jurisdictional limitations in many cases.
By developing a set of policies that reinforce and strengthen one another, it is possible for registries – especially new registries – to implement effective systems that cover all the proposed GAC safeguards.
The GAC safeguard advice include a further set of five and a third set of three safeguards for a large number of categorized applications.
IFFOR feels that the additional safeguards represent a best-faith effort on the part of the GAC to identify future public policy issues. It is of course not possible for all the permutations and combinations of possibilities and strings to be fully addressed and the GAC safeguard advice should be seen in that light.
IFFOR believes its experience may also be invaluable in this regard. A number of the policies we devised for ICM Registry were specific to its particular target audience. In order to produce policies that properly reflected the viewpoints of this group, our Policy Council was comprised of a majority of members from that particular "sponsored community".
We would propose that a similar system would work for other registries – with representatives from the relevant parties identified and pulled into specific policy discussions, on an “as needed basis”, per TLD.
IFFOR intends to offer registry-specific policy services to applicants with many of safeguards likely to be work across many registries while some policies (such as identifying relevant industry bodies) can be application or TLD-specific.
There is some understandable concern that the GAC safeguard advice may effectively oblige all of the 180+ named applicants to set up their own policy bodies – which comes at a cost in both time and resources. However, we would like ICANN to know that IFFOR intends to offer its services to the broad gTLD market which can immediately translate into substantially lower costs and higher quality, independent policies for new registries.
Thank you again for the opportunity to comment.
If you are interested in further details of IFFOR's Safeguard Policies, we have posted details on our website at http://iffor.org/policy/safeguard/.
Executive Director, IFFOR