Historical Resolution Tracking Feature » Safeguards Applicable to all New gTLDs
Important note: The explanatory text provided through this database (including the summary, implementation actions, identification of related resolutions, and additional information) is an interpretation or an explanation that has no official authority and does not represent the purpose behind the Board actions, nor does any explanations or interpretations modify or override the Resolutions themselves. Resolutions can only be modified through further act of the ICANN Board.
Safeguards Applicable to all New gTLDs
Resolved (2013.06.25.NG02), the NGPC adopts the "NGPC Proposal for Implementation of GAC Safeguards Applicable to All New gTLDs" (19 June 2013), attached as Annex I [PDF, 72 KB] to this Resolution, to accept the GAC's advice regarding Safeguards Applicable to All Strings.
Resolved (2013.06.25.NG03), the NGPC directs staff to make appropriate changes to the final draft of the New gTLD Registry Agreement, as presented in Annex II [PDF, 64 KB] attached to this Resolution, to implement certain elements of the GAC advice regarding Safeguards Applicable to All Strings.
Why the NGPC is addressing the issue?
Article XI, Section 2.1 of the ICANN Bylaws http://www.icann.org/en/about/governance/bylaws#XI permit the GAC to "put issues to the Board directly, either by way of comment or prior advice, or by way of specifically recommending action or new policy development or revision to existing policies." The GAC issued advice to the Board on the New gTLD Program through its Beijing Communiqué dated 11 April 2013. The ICANN Bylaws require the Board to take into account the GAC's advice on public policy matters in the formulation and adoption of the polices. If the Board decides to take an action that is not consistent with the GAC advice, it must inform the GAC and state the reasons why it decided not to follow the advice. The Board and the GAC will then try in good faith to find a mutually acceptable solution. If no solution can be found, the Board will state in its final decision why the GAC advice was not followed.
What is the proposal being considered?
The NGPC is being asked to consider accepting a discrete grouping of the GAC advice as described in the attached "NGPC Proposal for Implementation of GAC Safeguards Applicable to All New gTLDs" (Annex I [PDF, 72 KB]; 19 June 2013), which includes the six (6) items of safeguard advice from the Beijing Communiqué applicable to all new gTLDs. This advice is identified in the GAC Register of Advice as: (a) 2013-04-11-Safeguards-1, (b) 2013-04-11-Safeguards-2, (c) 2013-04-11-Safeguards-3, (d) 2013-04-11-Safeguards-4, (e) 2013-04-11-Safeguards-5, and (f) 2013-04-11-Safeguards-6 (collectively, the "Safeguards Applicable to All Strings").
Which stakeholders or others were consulted?
On 23 April 2013, ICANN initiated a public comment forum to solicit input on how the NGPC should address GAC advice regarding safeguards applicable to broad categories of new gTLD strings http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13.... The public comment forum closed on 4 June 2013. The NGPC has considered the community's comments in formulating its response to the GAC advice regarding Safeguards Applicable to All Strings. These comments also will serve as important inputs to the NGPC's future consideration of the other elements of GAC advice not being considered at this time in the attached annexes.
What concerns or issues were raised by the community?
ICANN received several responses from the community during the course of the public comment forum on broad categories of GAC safeguard advice. Of comments regarding safeguards applicable to all new gTLDs, approximately 29% of unique commenters expressed opposition whereas approximately 71% expressed support.
Regarding support, commenters expressed general agreement with the safeguards. Those expressing support also expressed concern over the method of implementation and that the GAC should not dictate the specific procedures for implementation. Supporters also indicated that some of these safeguards are already inherent in the 2013 RAA.
In adopting this Resolution, the NGPC specifically acknowledges comments from the community opposed to the NGPC accepting the GAC's advice. The NGPC takes note of comments asserting that adopting the GAC advice threatens the multi-stakeholder policy development process. ICANN's Bylaws permit the GAC to "consider and provide advice on the activities of ICANN as they relate to concerns of governments, particularly matters where there may be an interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues." (Art. XI, § 2.1.a) The GAC issued advice to the Board on the New gTLD Program through its Beijing Communiqué dated 11 April 2013. The ICANN Bylaws require the Board (and the NGPC) to take into account the GAC's advice on public policy matters in the formulation and adoption of the polices, and if the Board (and the NGPC) takes an action that is not consistent with the GAC advice, it must inform the GAC and state the reasons why it decided not to follow the advice. The parties must then try in good faith to find a mutually acceptable solution. Thus, the GAC's advice is part of the multi-stakeholder process.
The posting of the Beijing Communiqué to solicit public comment on the broad categories of the GAC's safeguard advice demonstrates ICANN's commitment to a bottom-up, multi-stakeholder model, and provided stakeholders with approximately six weeks (including the public comment and reply periods) to analyze, review and respond to the proposed recommendations. The NGPC views finding a workable solution to the GAC's advice as a step forward as the community continues to respond to the needs of registrants, the community and all stakeholders.
The NGPC also took note of the comments from the community in opposition to ICANN implementing the safeguard advice concerning WHOIS verification checks to be performed by registry operators. The NGPC acknowledges the ongoing work in the community on WHOIS verification. In response to these comments in opposition, the NGPC accepted the spirit and intent of the GAC's advice on the WHOIS verification checks by having ICANN, instead of registry operators, implement the checks. ICANN is concluding its development of a WHOIS tool that gives it the ability to check false, incomplete or inaccurate WHOIS data, as the Board previously directed staff in Board Resolutions 2012.11.08.01 - 2012.11.08.02 to begin to "proactively identify potentially inaccurate gTLD data registration in gTLD registry and registrar services, explore using automated tools, and forward potentially inaccurate records to gTLD registrars for action; and 2) publicly report on the resulting actions to encourage improved accuracy." . Given these ongoing activities, the NGPC determined that ICANN (instead of Registry Operators) is well positioned to implement the GAC's advice.
With respect to mitigating abusive activity, the NGPC acknowledges the comments noting that registries do not have relationships with registrants and should not be required to determine whether a registrant is in compliance with applicable laws. To address this concern, the NGPC included language in the PIC Specification that would obligate registry operators to include a provision in their Registry-Registrar Agreements that requires registrars to include in their Registration Agreements a provision prohibiting registered name holders from distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related procedures) consequences for such activities including suspension of the domain name.
With respect to the safeguards regarding security checks, the NGPC considered that the comments in opposition raise important questions about the costs and timing of implementing this measure, and the scope and framework of the security checks. The NGPC is mindful that there are various ways a registry operator could implement the required security checks, and has taken these concerns into consideration in its response to the GAC's advice. The NGPC's response directs ICANN to solicit community participation (including conferring with the GAC) in a task force or through a policy development process in the GNSO, as appropriate, to develop the framework for Registry Operators to respond to identified security risks that pose an actual risk of harm, notification procedures, and appropriate consequences, including a process for suspending domain names until the matter is resolved, while respecting privacy and confidentiality. The proposed implementation of the GAC's advice is phased to account for the commenters' concerns. The proposed language in the PIC Specification will provide the general guidelines for what registry operators must do, but omits the specific details from the contractual language to allow for the future development and evolution of the parameters for conducting security checks.
With respect to consequences in the safeguards applicable to all strings, the NGPC took note of the commenters' concerns that this item of safeguard advice is already addressed in the 2013 RAA and by the WHOIS Data Problem Report system. The GAC's concerns are addressed in the existing framework and the NGPC is not proposing to duplicate the existing enforcement models.
The NGPC also takes note of the comments requesting that the GAC advice be rejected as "last-minute" or "untimely." The commenters asserted that this introduces uncertainty into the Program and the makes material changes to the AGB. As an alternative to accepting the advice, the NGPC considered the timing consequences if the NGPC rejected the advice. The NGPC took note of the procedure for any consultations that might be needed if the Board (and the NGPC) determines to take an action that is not consistent with GAC advice, which was developed by the ICANN Board-GAC Recommendation Implementation Working Group (BGRI-WG). The procedure was approved by the BGRI-WG in Beijing and would be used for any consultation on this GAC advice. The procedure says that the consultation process should conclude within six months, but that the GAC and the Board can agree to a different timetable. On balance, the NGPC determined that entering into a consultation process on this particular section of the safeguard advice would introduce greater uncertainty into the Program than if the NGPC found a workable solution to accept and implement the GAC's safeguard advice applicable to all strings.
The complete set of comments can be reviewed at: http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13....
What significant materials did the NGPC review?
As part of its deliberations, the NGPC reviewed the following significant materials and documents:
GAC Beijing Communiqué: http://www.icann.org/en/news/correspondence/gac-to-board-18apr13-en.pdf [PDF, 156 KB]
Public comments in response to broad categories of GAC safeguard advice: http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13...
Report of Public Comments, New gTLD Board Committee Consideration of GAC Safeguard Advice dated 18 June 2013: http://www.icann.org/en/news/public-comment/report-comments-gac-safeguar...
What factors did the NGPC find to be significant?
The Beijing Communiqué generated significant interest from the community and resulted in many comments. The NGPC considered the community comments, the GAC's advice transmitted in the Beijing Communiqué, and the procedures established in the AGB for addressing GAC advice to the New gTLD Program.
Are there positive or negative community impacts?
The adoption of the GAC advice as provided in the attached annexes will assist with resolving the GAC advice in manner that permits the greatest number of new gTLD applications to continue to move forward as soon as possible.
Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?
There are no foreseen fiscal impacts associated with the adoption of this resolution.
Are there any security, stability or resiliency issues relating to the DNS?
Approval of the proposed resolution will not impact security, stability or resiliency issues relating to the DNS.
Is this either a defined policy process within ICANN's Supporting Organizations or ICANN's Organizational Administrative Function decision requiring public comment or not requiring public comment?
On 23 April 2013, ICANN initiated a public comment forum to solicit input on how the NGPC should address GAC advice regarding safeguards applicable to broad categories of new gTLD strings http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13.... The public comment forum closed on 4 June 2013.