ICANN/GNSO GNSO Email List Archives

[council]


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

[council] Letter from ICANN Board to GAC on Enforcing new gTLD applicant commitments

  • To: "council@xxxxxxxxxxxxxx" <council@xxxxxxxxxxxxxx>
  • Subject: [council] Letter from ICANN Board to GAC on Enforcing new gTLD applicant commitments
  • From: Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
  • Date: Wed, 13 Feb 2013 00:12:28 +0000
  • Accept-language: en-AU, en-US
  • List-id: council@xxxxxxxxxxxxxx
  • Sender: owner-council@xxxxxxxxxxxxxx
  • Thread-index: Ac4JfhQ/K9/J5fgNShOBsuo4GhBbLA==
  • Thread-topic: Letter from ICANN Board to GAC on Enforcing new gTLD applicant commitments

Hello All,

Please see attached letter from the chair of the ICANN Board to the GAC chair 
regarding Enforcing Applicant Commitments.

Below is a plain text summary.

Regards,
Bruce Tonkin


Dear Heather,

On behalf of the Board, I write to follow up on our commitment in our letter of 
16 January 2013, to provide
a report on our efforts to address one item of advice contained in the GAC 
Toronto Communiqué.

Background

In its Toronto Communiqué, the GAC requested a written briefing from the ICANN 
Board on "how
ICANN will ensure that any commitments made by [New gTLD] applicants, in their 
applications or as a
result of any subsequent changes, will be overseen and enforced by ICANN." The 
GAC advised the Board
that, "it is necessary for all of these statements of commitment and objectives 
to be transformed into
binding contractual commitments, subject to compliance oversight by ICANN."

In our letter of 16 January 2013, we indicated that there was no existing 
mechanism in the New gTLD
program to address the GAC's concerns. To respond to the GAC's advice and the 
concerns raised by
others in the community, staff was asked to develop possible mechanisms to 
transform applicant
commitments (either as set forth within their applications or arising from 
early warning discussions
between applicants and governments) into contractually binding and enforceable 
obligations.  The Board
considered the staff proposals at the Board Workshop in Los Angeles on 31 
January 2013 - 2 February
2013.

I am happy to report that ICANN has undertaken specific steps to address this 
item of GAC advice.  On 1
February 2013, the New gTLD Program Committee adopted a resolution directing 
ICANN's President and
CEO to seek public comment on a proposed "Public Interest Commitments" 
specification ("PIC Spec") to
be added to each new gTLD registry agreement.

(http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-01feb13-en.htm
 )

On 5 February 2013, ICANN opened a public comment forum seeking comment on a 
revised draft of the
New gTLD Registry Agreement that includes the new PIC Spec.
 (http://www.icann.org/en/news/publiccomment/base-agreement-05feb13-en.htm )


"Public Interest Commitments"

The proposed PIC Spec is a mechanism by which applicants may incorporate 
additional commitments into
their Registry Agreements.  As proposed, the PIC Spec has one mandatory 
provision and two optional
provisions.  It would require the Registry Operator to use only those 
registrars that sign onto the 2013
Registrar Accreditation Agreement.  It would also allow the Registry Operator 
to contractually agree to
follow the commitments made in certain sections of its application for the gTLD 
(the specific sections to be
selected by the Registry Operator).  Finally, it would allow the Registry 
Operator to identify specific
additional commitments - which could be even broader than those undertaken in 
the application - that it
will follow in the operation of the registry.

Each PIC Spec completed by an applicant would be posted for public review in 
advance of the Beijing
meeting.   Once finalized, the relevant PIC Spec would be attached to the 
relevant Registry Agreement. The
Registry Agreement would not be signed until the PIC Spec is completed.


Enforcement

The commitment to use only Registrars that have signed the new RAA will be 
enforceable through the
regular contractual compliance process within ICANN.  The additional 
commitments would primarily be
enforceable by third parties through a revised Post-Delegation Dispute 
Resolution Process.

Once the Registry Agreement is in operation, third parties who suffer actual 
harm as a result of the Registry
Operator's alleged noncompliance with the additional commitments or 
restrictions contained in the PIC
Spec would have standing to proceed to dispute resolution.  This dispute 
resolution procedure would be
made part of the existing Registry Restriction Post Delegation Dispute 
Resolution Procedure (PDDRP) and
Trademark PDDRP  http://newgtlds.icann.org/en/applicants/agb .

First, there would be a mandatory conciliation phase during which the third 
party and the Registry Operator
are expected to try to informally resolve the issue.  If the issue cannot be 
resolved, the third party
complainant will then proceed to a Public Interest Commitment Dispute 
Resolution Procedure (PIC-DRP)
operated by a dispute resolution provider.

If the provider issues findings and recommendations that the Registry Operator 
is violating the PIC Spec,
the matter would then proceed to ICANN's Contractual Compliance for enforcement.


Timeframe

As noted above, the PIC Spec and other proposed revisions to the Registry 
Agreement were posted for
public comment on 5 February 2013.  Applicants were also invited to optionally 
designate which parts of
their application and which additional promises they will agree to have 
included in their registry agreement.

Applicants' PICs are due on 5 March 2013, and will be publicly posted for 
public and GAC review.

I hope that you find the above responsive to the GAC's request for a written 
briefing on enforcing applicant
commitments and that it addresses the GAC's advice on this subject.

Best regards,
Stephen D. Crocker,
Chair, ICANN Board

Attachment: Letter to GAC - Enforcing Applicant Commitments.pdf
Description: Letter to GAC - Enforcing Applicant Commitments.pdf



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