ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

IFFOR's thoughts and proposed solution to GAC safeguard advice

  • To: comments-gac-safeguard-advice-23apr13@xxxxxxxxx
  • Subject: IFFOR's thoughts and proposed solution to GAC safeguard advice
  • From: Kieren McCarthy <kmccarthy@xxxxxxxxx>
  • Date: Tue, 14 May 2013 08:55:27 -0700

Dear ICANN New gTLD Board Committee

Please find included below and attached as a document the International
Foundation for Online Responsibility's (IFFOR) comments on GAC Safeguard
Advice for new gTLDs.

Best regards,

Kieren McCarthy

Executive Director, IFFOR


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

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

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.

Applicable law

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.

Other 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/safeguard.

 Kieren McCarthy

Kieren McCarthy

Executive Director, IFFOR
+1 310 806 1451

Twitter <https://twitter.com/iffor_org> |
LinkedIn <http://www.linkedin.com/company/iffor>

Attachment: iffor-public-comment-response-gac-safeguard-advice.pdf
Description: Adobe PDF document

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy