NGPC Progress on Addressing GAC Beijing Advice on New gTLDs
- 2013-04-11-Obj-Africa (Communiqué §1.a.i.1)
- 2013-04-11-Obj-GCC (Communiqué §1.a.i.2)
- 2103-04-11-Religious Terms (Communiqué §1.a.ii)
- 2013-04-11-gTLDStrings (Communiqué §1.c)
- Request for Written Briefing (Communiqué §1.d)
https://gacweb.icann.org/download/attachments/28278832/NGPC%20Scorecard%20of%201As%20Regarding%20Non-%C2%ADSafeguard%20Advice%20in%20the%20GAC%20Beijing%20Communique%CC%81.pdf?version=1&modificationDate=1372384291000&api=v2 [PDF, 2.68 MB]
- 2013-04-11-CommunitySupport (Communiqué §1.e)
- 2013-04-11-PluralStrings (Communiqué §1.f)
- After careful consideration of the issues, review of the comments raised by the community, the process documents of the expert review panels, and deliberations by the NGPC, the NGPC determined that no changes to the ABG are needed to address potential consumer confusion specifically resulting from allowing singular and plural versions of the same strings.
- The NGPC considered several significant factors during its deliberations about whether to allow singular and plural version of the same strings. The NGPC had to balance the competing interests of each factor to arrive at a decision.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.d.
- 2013-04-11-IGO (Communiqué §1.g)
- The New gTLD Registry Agreement will require operators to provide appropriate preventative initial protection for the IGO identifiers. These protections will remain in place while the GAC, NGPC, ICANN Staff and community continue to actively work through outstanding implementation issues.
- If the NGPC and GAC do not reach an agreement on outstanding implementation issues for protecting IGO names and acronyms by the first meeting of the NGPC following the ICANN 47 meeting in Durban, and subject to any matters that arise during the discussions, registry operators will be required to protect only the IGO names (and not the acronyms) identified on the GAC’s IGO List.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-RAA (Communiqué §2)
- 2013-04-11-WHOIS (Communiqué §3)
- 2013-04-11-IOCRC (Communiqué §4)
- The NGPC accepted the GAC advice.
- The Registry Agreement includes protection for an indefinite duration for IOC/RCRC names. Specification 5 of this version of the Registry Agreement includes a list of names (provided by the IOC and RCRC Movement) that “shall be withheld from registration or allocated to Registry Operator at the second level within the TLD.”
- This protection was added pursuant to a NGPC resolution to maintain these protections “until such time as a policy is adopted that may require further action” (204.11.26.NG03).
- The resolution recognized the GNSO’s initiation of an expedited PDP. Until such time as the GNSO approves recommendations in the PDP and the Board adopts them, the NGPC’s resolutions protecting IOC/RCRC names will remain in place.
- Should the GNSO submit any recommendations on this topic, the NGPC will confer with the GAC prior to taking action on any such recommendations.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-04jun13-en.htm and http://www.icann.org/en/groups/board/documents/new-gtld-resolution-annex-1-04jun13-en.pdf [PDF, 564 KB]
- 2013-04-11-PIC SPEC (Communiqué §5, Annex 2)
- 2013-04-11-Safeguards 1 (Communiqué Annex 1, 1)
- ICANN (instead of Registry Operators) will implement the GAC’s advice that checks identifying registrations in a gTLD with deliberately false, inaccurate or incomplete WHOIS data be conducted at least twice a year.
- ICANN will perform a periodic sampling of WHOIS data across registries in an effort to identify potentially inaccurate records.
- ICANN will also maintain statistical reports that identify the number of inaccurate WHOIS records identified.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards 2 (Communiqué Annex 1, 2)
- A provision in the proposed New gTLD Registry Agreement (as a mandatory Public Interest Commitment in Specification 11) obligates 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.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards 3 (Communiqué Annex 1, 3)
- A provision in the New gTLD Registry Agreement (as a mandatory Public Interest Commitment in Specification 11) requires Registry Operators periodically to conduct a technical analysis to assess whether domains in its gTLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets.
- The provision also requires Registry Operators to maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks. Registry Operators will maintain these reports for the agreed contracted period and provide them to ICANN upon request. The contents of the reports will be publically available as appropriate.
- Because there are multiple ways for a Registry Operator to implement the required security checks, ICANN will 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 language included in Paragraph 3 of the attached PIC Specification provides 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. This will permit Registry Operators to enter into agreements as soon as possible, while allowing for a careful and fulsome consideration by the community on the implementation details.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards 4 ((Communiqué Annex 1, 4)
- As detailed in item 13 above, ICANN will maintain statistical reports that identify the number of inaccurate WHOIS records identified as part of the checks to identify registrations with deliberately false, inaccurate or incomplete WHOIS data.
- As detailed in item 15 above, Registry Operators will be required to maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks.
- Registry Operators will maintain these reports for the agreed contracted period and provide them to ICANN upon request. The contents of the reports will be publically available as appropriate.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards 5 ((Communiqué Annex 1, 5)
- Registry Operators are required to ensure that there is a mechanism for making complaints to the Registry Operator regarding malicious conduct in the TLD.
- Section 4.1 of Specification 6 of the New gTLD Registry Agreement provides that, “Registry Operator shall provide to ICANN and publish on its website its accurate contact details including a valid email and mailing address as well as a primary contact for handling inquires related to malicious conduct in the TLD, and will provide ICANN with prompt notice of any changes to such contact details.”
- Section 2.8 of the New gTLD Registry Agreement provides that a, “Registry Operator shall take reasonable steps to investigate and respond to any reports from law enforcement and governmental and quasi-governmental agencies of illegal conduct in connection with the use of the TLD.”
- ICANN operates the WHOIS Data Problem Reports System <http:/forms.icann.org/en/resources/compliance/complaints/whois/inaccuracy-form>, which is a mechanism for making complaints that WHOIS information is inaccurate.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards 6 (Communiqué Annex 1, 6)
- Consequences for the demonstrated provision of false WHOIS information are set forth in Section 3.7.7.2 of the 2013 RAA <http://www.icann.org/en/resources/registrars/raa/proposed-agreement-22apr13-en.pdf> [PDF, 311 KB]: “A Registered Name Holder’s willful provision of inaccurate or unreliable information, its willful failure to update information provided to Registrar within seven (7) days of any change, or its failure to respond for over fifteen (15) days to inquiries by Registrar concerning the accuracy of contact details associated with the Registered Name Holder’s registration shall constitute a material breach of the Registered Name Holder-registrar contract and be a basis for suspension and/or cancellation of the Registered Name registration.”
- Paragraph 1 of the PIC Specification includes a requirement that Registry Operator will use only ICANN accredited registrars that are party to the 2013 RAA so that these consequences are contractually required.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.b.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 1)
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC’s Category 2.1 Safeguard Advice regarding “Restricted Access” since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC’s Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 2)
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC’s Category 2.1 Safeguard Advice regarding “Restricted Access” since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC’s Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 3)
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC’s Category 2.1 Safeguard Advice regarding “Restricted Access” since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC’s Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 4)
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC’s Category 2.1 Safeguard Advice regarding “Restricted Access” since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC’s Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 5)
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC’s Category 2.1 Safeguard Advice regarding “Restricted Access” since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC’s Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 6)
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC’s Category 2.1 Safeguard Advice regarding “Restricted Access” since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC’s Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 7)
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC’s Category 2.1 Safeguard Advice regarding “Restricted Access” since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC’s Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-1 (Communiqué Annex 1, Category 1, 8)
- After considering the community comments, the NGPC decided to begin a dialogue with the GAC during the ICANN Meeting in Durban to clarify the scope of the requirements provided in the Category 1 Safeguard Advice. The dialogue with the GAC on Category 1 will also include discussion of GAC’s Category 2.1 Safeguard Advice regarding “Restricted Access” since that advice applies to the strings listed under Category 1. Pending the dialogue with the GAC, staff will defer moving forward with the contracting process for applicants who have applied for TLD strings listed in the GAC’s Category 1 Safeguard Advice.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm.
- 2013-04-11-Safeguards-Categories-2 (Communiqué Annex 1, Category 2, 1)
1. Restricted Access
As an exception to the general rule that the gTLD domain name space is operated in an open manner registration may be restricted, in particular for strings mentioned under category 1 above. In these cases, the registration restrictions should be appropriate for the types of risks associated with the TLD. The registry operator should administer access in these kinds of registries in a transparent way that does not give an undue preference to any registrars or registrants, including itself, and shall not subject registrars or registrants to an undue disadvantage.
- Safeguards-Categories-2 (Communiqué Annex 1, Category 2, 2)
2. Exclusive Access
For strings representing generic terms, exclusive registry access should serve a public interest goal.
- For applicants seeking to impose exclusive registry access for “generic strings”, the NGPC directed staff to defer moving forward with the contracting process for these applicants, pending a dialogue with the GAC.
- The term “generic string” is defined to mean “a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others.”
- Exclusive registry access is defined as limiting registration of a generic string exclusively to a single person or entity and their affiliates.
- For applicants not seeking to impose exclusive registry access, a provision in the in the New gTLD Registry Agreement requires TLDs to operate in a transparent manner consistent with general principles of openness and non-discrimination.
- A PIC Specification also includes a provision to preclude registry operators from imposing eligibility criteria that limit registration of a generic string exclusively to a single person or entity and their “affiliates.”
- All applicants will be required to respond by a specified date indicating whether (a) the applicant is prepared to accept the proposed PIC Specification that precludes exclusive registry access or (b) the applicant is unwilling to accept the proposed PIC Specification because the applicant intends to implement exclusive registry access.
- The NGPC will enter into a dialogue with the GAC to seek clarification on their advice with respect to exclusive registry access.
- See http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.c.
Comments are closed.