Motion 1. WHOIS Registrant Identification Study Motion May 2011
Made by Jonathan Robinson
Seconded by: John Berard
Whereas:
In October 2007, the GNSO Council concluded that a comprehensive and objective understanding of key factual issues regarding the gTLD Whois system would benefit future GNSO policy development efforts (http://gnso.icann.org/resolutions/).
On 4 March 2009, the GNSO Council requested Staff to conduct research on feasibility and cost estimates for selected Whois studies and report its findings to Council. (See Motion 3, http://gnso.icann.org/resolutions/#200903).
On 23-Mar-2010, Staff presented a report on the feasibility and cost estimates for a Whois "Registrant Identification" Study, finding that the study would cost approximately $150,000 (USD) and take approximately one year to complete (http://gnso.icann.org/issues/whois/whois-studies-report-for-gnso-23mar10-en.pdf). This exploratory study would examine Whois data for a representative sample of gTLD domain names to classify the types of entities that register domains, including natural persons, various kinds of legal persons and Privacy and Proxy service providers.
On 28 April 2011 the Council deferred consideration of the Whois Registrant Identification Study until the 9 June 2011 meeting and requested that any applicable motions in that regard be submitted not later than 1 June 2011.
On 20 May 2011 a volunteer Whois studies group submitted to the GNSO Council revised Whois Registrant Identification Study Terms of Reference
http://gnso.icann.org/issues/whois/tor-whois-registrant-id-studies-20may11-en.pdf
supporting Rationale
http://gnso.icann.org/issues/whois/whois-registrant-id-study-rationale-20may11-en.pdf
and Summary of Changes
http://gnso.icann.org/issues/whois/summary-changes-whois-registrant-id-study-tor-20may11-en.pdf
Resolved;
The Council requests that ICANN staff proceed with the Whois Registrant Identification Study as set forth in the revised Terms of Reference http://gnso.icann.org/issues/whois/tor-whois-registrant-id-studies-20may11-en.pdf
Further resolved, the Council asks staff to report back to the Council if the original estimate for the study of $150,000 USD is exceeded by greater than 20%.
Further resolved, in recognition of the substantial amount of coordination needed to direct the research, that staff be given the discretion to manage this study serially or in parallel with the other Whois studies, with a goal of expediting completion of all of the studies as efficiently as possible.
2. Motion regarding the JAS milestone report.
Made by: Rafik Dammak
Seconded by: Andrei Kolesnikov
Amended by Jeff Neuman (Resolved clauses with certain of the original text stricken)
Whereas:
The GNSO council and ALAC established the Joint SO/AC Working Group (JASWG) on support for new gTLD applicants in April of 2010; and
The Working Group released it Milestone Report posted for consideration by the Board, Chartering Organizations and at-large Community. This report documented the completion of work as defined in the orignal charter and requested an update to the Working Groups charter, and
The GNSO and ALAC, separately, renewed the Working Groups charter with additional work item in February 2011, and
The Joint SO/AC Working Group received and discussed the public comments, and
The Joint SO/AC Working Group has completed the work as defined in its extended charter and published a second milestone report (https://community.icann.org/display/jaswg/JAS+Issues+and+Recommendations#) on 8 May 2011 covering those chartered items (http://gnso.icann.org/resolutions/#20110113-1) entitled JAS Milestone Report. and
The GNSO council does not wish to delay the start of the new gTLD application process, and
The GNSO council does not wish to delay implementation of support programs for applicants from developing regions,
Resolved:
The GNSO Council thanks the members of the Joint SO/AC Working Group for its efforts and its dedication to completing the work on such a tight schedule, and
The GNSO Council request that the report be put out for community review as soon as possible,
The GNSO Council approves forwarding the second JAS Milestone Report to the ICANN board for review and approval, and
The GNSO Council request ICANN staff begin working on implementation of the recommendation pending Board approval, and
The JAS Working Group continues working to deal with any issues that may arise in the upcoming review by the community, and the Board and from the Staff in the process of implementing the proposals, and
That the JAS Working group publish their final report after this review process.
Resolved further, that the GNSO Council instructs the GNSO Chair to communicate its decision to the ALAC Chair.
Motion 3: To Acknowledge the Receipt of the Policy Development Process Work Team Final Report and Initiate a Public Comment Period
Made by: Jeff Neuman
Seconded by: Wolf-Ulrich Knoben
WHEREAS, in October 2008, the GNSO Council established a framework (see GNSO Council Improvement Implementation Plan;
(http://www.icann.org/en/topics/gnso-improvements/gnso-improvements-implementation-plan-16oct08.pdf) for implementing the various GNSO Improvements identified and approved by the ICANN Board of Directors on 26 June 2008
(http://www.icann.org/en/minutes/resolutions-26jun08.htm#_Toc76113182)
(http://www.icann.org/en/minutes/resolutions-26jun08.htm);
WHEREAS, that framework included the formation, in January 2009, of two Steering Committees, the Operations Steering Committee (OSC) and the Policy Process Steering Committee (PPSC), to charter and coordinate the efforts of five community work teams in developing specific recommendations to implement the improvements;
WHEREAS, the PPSC established two work teams, including the Policy Development Process Work Team (PDP-WT), which was chartered to develop a new policy development process that incorporates a working group approach and makes it more effective and responsive to ICANN’s policy development needs;
WHEREAS, the GNSO Council decided to terminate the PPSC on 28 April 2011 and instructed the PDP-WT to deliver its Final Report directly to the GNSO Council;
WHEREAS, the PDP-WT submitted its Final Report, http://www.icann.org/en/announcements/announcement-31may11-en.htm, on 31 May 2011 to the GNSO Council;
NOW THEREFORE, BE IT:
RESOLVED that the GNSO Council acknowledges receipt of the PDP-WT Final Report as delivered by the PDP-WT and directs ICANN Staff to commence a thirty (30) day public comment period on this Final Report.
RESOLVED FURTHER that the GNSO Council shall take action on the PDP-WT Final Report as soon as possible after the end of the public comment period.
RESOLVED FURTHER that the GNSO Council recommends that a concise summary of the new Policy Development Process be drafted by ICANN Staff, following approval of the new PDP by the ICANN Board, in order to serve as a primer to the new Annex A of the ICANN Bylaws and PDP Manual for potential PDP WG members.
Motion 4 on the Adoption of the IRTP Part B Final Report and Recommendations
Made by: Tim Ruiz
Seconded by:
WHEREAS on 24 June 2009, the GNSO Council launched a Policy Development Process (PDP) on IRTP Part B addressing the following five charter questions:
- Whether a process for urgent return/resolution of a domain name should be developed, as discussed within the SSAC hijacking report
(http://www.icann.org/announcements/hijacking-report-12jul05.pdf); see also (http://www.icann.org/correspondence/cole-to-tonkin-14mar05.htm); - Whether additional provisions on undoing inappropriate transfers are needed, especially with regard to disputes between a Registrant and Admin Contact (AC). The policy is clear that the Registrant can overrule the AC, but how this is implemented is currently at the discretion of the registrar;
- Whether special provisions are needed for a change of registrant when it occurs near the time of a change of registrar. The policy does not currently deal with change of registrant, which often figures in hijacking cases;
- Whether standards or best practices should be implemented regarding use of a Registrar Lock status (e.g. when it may/may not, should/should not be applied);
- Whether, and if so, how best to clarify denial reason #7: A domain name was already in 'lock status' provided that the Registrar provides a readily
accessible and reasonable means for the Registered Name Holder to remove the lock status.
WHEREAS this PDP has followed the prescribed PDP steps as stated in the Bylaws, resulting in a Final Report delivered on 30 May 2011;
WHEREAS the IRTP Part B WG has reached full consensus on the recommendations in relation to each of the five issues outlined above;
WHEREAS the GNSO Council has reviewed and discussed these recommendations.
RESOLVED (A), the GNSO Council recommends to the ICANN Board of Directors:
- Requiring Registrars to provide a Transfer Emergency Action Contact (TEAC). To this end the language of section 4 (Registrar Coordination) and Section 6 (Registry Requirements of the Inter-Registrar Transfer Policy should be updated as follows:
Transfer Emergency Action Contact (Append to Section 4)
Registrars will establish a Transfer Emergency Action Contact (TEAC) for urgent communications relating to transfers. The goal of the TEAC is to quickly establish a real-time conversation between registrars (in a language that both parties can understand) in an emergency. Further actions can then be taken towards a resolution, including initiating existing (or future) transfer dispute or undo processes.
Communications to TEACs will be reserved for use by ICANN-Accredited Registrars, gTLD Registry Operators and ICANN Staff. The TEAC point of contact may be designated as a telephone number or some other real-time communication channel and will be recorded in, and protected by, the ICANN RADAR system.
Communications to a TEAC must be initiated in a timely manner, within a reasonable period of time following the alleged unauthorized loss of a domain.
Messages sent via the TEAC communication channel must generate a non-automated response by a human representative of the gaining Registrar. The person or team responding must be capable and authorized to investigate and address urgent transfer issues. Responses are required within 4 hours of the initial request, although final resolution of the incident may take longer.
The losing registrar will report failures to respond to a TEAC communication to ICANN Compliance and the registry operator. Failure to respond to a TEAC communication may result in a transfer-undo in accordance with Section 6 of this policy and may also result in further action by ICANN, up to and including non-renewal or termination of accreditation.
Both parties will retain correspondence in written or electronic form of any TEAC communication and responses, and share copies of this documentation with ICANN and the registry operator upon request. This documentation will be retained in accordance with Section 3.4 of the Registrar Accreditation Agreement (RAA). Users of the TEAC communication channel should report non-responsive Registrars to ICANN. Additionally, ICANN may conduct periodic tests of the Registrar TEAC communication channel in situations and a manner deemed appropriate to ensure that registrars are indeed responding to TEAC messages.
(Append to Section 6) 6 iv. Documentation provided by the Registrar of Record prior to transfer that the Gaining Registrar has not responded to a message via the TEAC within the timeframe specified in Section 4.
In addition, update section 6 to reflect that the registry, in case of a transfer undo, will reverse the transfer and reset the registrar of record filed to its original state (‘In such case, the transfer will be reversed and the Registrar of Record field domain name reset to its original state’). (IRTP Part B Recommendation #1)
- Modifying section 3 of the IRTP to require that the Registrar of Record/Losing Registrar be required to notify the Registered Name Holder/Registrant of the transfer out. The Registrar of Record has access to the contact information for the Registrant and could modify their systems to automatically send out the Standardized Form for Losing Registrars ("Confirmation FOA") to the Registrant. (IRTP Part B Recommendation #5)
- Modifying Reason for Denial #6 as follows: Express objection to the transfer by the authorized Transfer Contact. Objection could take the form of specific request (either by paper or electronic means) by the authorized Transfer Contact to deny a particular transfer request, or a general objection to all transfer requests received by the Registrar, either temporarily or indefinitely. In all cases, the objection must be provided with the express and informed consent of the authorized Transfer Contact on an opt-in basis and upon request by the authorized Transfer Contact, the Registrar must remove the lock or provide a reasonably accessible method for the authorized Transfer Contact to remove the lock within five (5) calendar days. (IRTP Part B Recommendation #6)
RESOLVED (B), the GNSO Council recommends the promotion by ALAC and other ICANN structures of the measures outlined in the recent report of the Security and Stability Advisory Committee on A Registrant's Guide to Protecting Domain Name Registration Accounts (SAC 044). In particular, the GNSO Council recommends that registrants consider the measures to protect domain registrar accounts against compromise and misuse described in SAC044, Section 5. These include practical measures that registrants can implement "in house", such as ways to protect account credentials and how to incorporate domain name registrations into employee or resource management programs typically found in medium and large businesses. It suggests ways that registrants can use renewal and change notifications from registrars as part of an early warning or alerting system for possible account compromise. The GNSO Council Chair will reach out to the ALAC and other ICANN structures to inform them of this recommendation and discuss how the GNSO may contribute to this promotion. (IRTP Part B Recommendation #2)
RESOLVED (C), the GNSO Council recommends that if a review of the UDRP is conducted in the near future, the issue of requiring the locking of a domain name subject to UDRP proceedings is taken into consideration. (IRTP Part B Recommendation #7)
RESOLVED (D), (Recommendation #8) (Recommendation #9)
RESOLVED (E), the GNSO Council requests an Issues Report on the requirement of ‘thick’ WHOIS for all incumbent gTLDs. Such an Issue Report and possible subsequent Policy Development Process should not only consider a possible requirement of 'thick' WHOIS for all incumbent gTLDs in the context of IRTP, but should also consider any other positive and/or negative effects that are likely to occur outside of IRTP that would need to be taken into account when deciding whether a requirement of 'thick' WHOIS for all incumbent gTLDs would be desirable or not. (IRTP Part B Recommendation #3)
RESOLVED (F), the GNSO Council requests an Issue Report on IRTP Part C, which should include:
- “Change of Control” function, including an investigation of how this function is currently achieved, if there are any applicable models in the country-code name space that can be used as a best practice for the gTLD space, and any associated security concerns. It should also include a review of locking procedures, as described in Reasons for Denial #8 and #9, with an aim to balance legitimate transfer activity and security. (IRTP Part B Recommendation #4)
- Whether provisions on time-limiting FOAs should be implemented to avoid fraudulent transfers out. For example, if a Gaining Registrar sends and receives an FOA back from a transfer contact, but the name is locked, the registrar may hold the FOA pending adjustment to the domain name status, during which time the registrant or other registration information may have changed.
- Whether requirements should be in place for Registrars of Record to send an FOA to the Registrant or Admin Contact. [Is this issue addressed by IRTP Part B Recommendation #5?]
- Whether the process could be streamlined by a requirement that registries use IANA IDs for registrars rather than proprietary IDs.
