1. Motion on the Adoption of the IRTP Part B Recommendation #3 (Issue Report on ‘Thick’ WHOIS)
Made by:Tim Ruiz
Seconded by: Stéphane van Gelder
WHEREAS on 24 June 2009, the GNSO Council launched a Policy Development Process (PDP) on IRTP Part B addressing the following five charter questions:
a. 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)
b. 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;
c. 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;
d. 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);
e. 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;
WHEREAS the GNSO Council resolved at its meeting on 22 June to ‘consider IRTP Part B Recommendation #3 concerning the request of an Issue Report on the requirement of 'thick' WHOIS for all incumbent gTLDs at its next meeting on 21 July’.
RESOLVED, the GNSO Council requests an Issue 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 or 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)
2. Motion to extend the mandate of the Joint ccNSO/GNSO IDN Working Group (JIG)
Made by: Rafik Dammak
Seconded by:
Whereas
The Joint ccNSO/GNSO IDN Working Group (JIG) was created by mutual charters of the ccNSO (http://ccnso.icann.org/workinggroups/jiwg-charter.pdf) and the GNSO (http://gnso.icann.org/resolutions/#200907); and
Both the IDN ccTLD Fast Track Implementation Plan and the new gTLD process have been approved by the Board of Directors, bringing into effect the JIG charter condition: Upon adoption of either the IDN ccTLD Fast Track Implementation Plan or the new gTLD process by the ICANN Board of Directors, the WG will be closed, unless both the ccNSO and GNSO Council extend the duration of the JIG WG.; and
The JIG identified 3 issues of common interest: 1. Single Character IDN TLDs; 2. IDN Variant TLDs; and, 3. Universal Acceptance of IDN TLDs; and
The JIG has delivered a first report on Item 1 “Implementation of Single Character IDN TLD” to the ccNSO council and the GNSO council on 30 March 2011; and
The GNSO Council and the ccNSO Council approved the report on April 7, 2011 and May 10, 2011 respectively; and
The final report on the first item of interest was delivered to the ICANN Board on May 11, 2011; and
Two issues of common interest remain from the JIG charter; and
The JIG WG has discussed and proposed the following target timeline for completion of the remaining items of common interest:
• 2011 Jul/Aug: Stocktaking & Development Initial Report for #3 (Public comments Sep 2011)
• 2011 Sep/Oct: Completion of Initial Report for #2 (Public comments Nov 2011)
• 2011 Nov/Dec: Completion of Draft Final Report for #2 (Public comments Feb/Mar 2012)
• 2012 Jan/Feb: Completion of Draft Final Report for #3 (Public comments Feb/Mar 2012)
• 2012 Mar: Finalization of Final Report for #2
• 2012 Apr: Finalization of Final Report for #3
• 2012 May-Oct: Implementation Follow up
Resolved
The JIG Working Group is extended through 2012 to complete work items Two (2. IDN Variant TLDs) and Three (3. Universal Acceptance of IDN TLDs ) from the original charter.
3. Motion on the Adoption of the PEDNR Final Report and Recommendations
Made by: Tim Ruiz
Seconded by: Stéphane van Gelder
Whereas on 7 May 2009, the GNSO Council launched a Policy Development Process (PDP) on Post-Expiration Domain Name Recovery (PEDNR) addressing the following five charter questions:
1. Whether adequate opportunity exists for registrants to redeem their expired domain names;
2. Whether expiration-related provisions in typical registration agreements are clear and conspicuous enough;
3. Whether adequate notice exists to alert registrants of upcoming expirations;
4. Whether additional measures need to be implemented to indicate that once a domain name enters the Auto-Renew Grace Period, it has expired (e.g., hold status, a notice on the site with a link to information on how to renew, or other options to be determined);
5. Whether to allow the transfer of a domain name during the RGP. Whereas this PDP has followed the prescribed PDP steps as stated in the ICANN Bylaws, resulting in a Final Report delivered on 14 June 2011;
Whereas the PEDNR WG has reached full consensus on the recommendations in relation to each of the five issues outlined above;
Whereas the PEDNR WG considers all the recommendations listed below as interdependent and has recommended that the GNSO Council should consider these recommendations as such;
Whereas the GNSO Council has reviewed and discussed these recommendations.
RESOLVED, the GNSO Council recommends to the ICANN Board of Directors:
(A):
1. Define “Registered Name Holder at Expiration” (RNHaE) as the entity or individual that was eligible to renew the domain name registration immediately prior to expiration. If the domain name registration was modified pursuant to a term of the Registration Agreement authorizing the modification of registration data for the purposes of facilitating renewal but not at the explicit request of the registrant, the RNHaE is the entity or individual identified as the registrant immediately prior to that modification. (PEDNR Recommendation #1)
2. For at least 8 consecutive days, at some point following expiration, the original DNS resolution path specified by the RNHaE, at the time of expiration, must be interrupted1 by the registrar, to the extent that the registry permits such interruptions, and the domain must be renewable by the RNHaE until the end of that period. This 8-day period may occur at any time following expiration. At any time during the 8 day period, the Registered Name Holder at Expiration may renew the domain with the Registrar and the Registrar, within a commercially reasonable delay, will restore the domain name to resolve to its original DNS resolution path prior to expiration. Notwithstanding, the Registrar may delete the domain at any time during the Autorenew grace period. (PEDNR Recommendation #2)
1 DNS interruption is defined as total Internet service interruption except for an informational web page (only one IP on which only port 80 is active).
3. If at any time after expiration when the Registered Name is still renewable by the RNHaE, the Registrar changes the DNS resolution path to effect a different landing website than the one used by the RNHaE prior to expiration, the page shown must explicitly say that the domain has expired and give instructions on how to recover the domain. Wording in the policy must make clear that “instructions” may be as simple as directing the RNHaE to a specific web site. (PEDNR Recommendation #3)
4. The RNHaE cannot be prevented from renewing a domain name registration as a result of WHOIS changes made by the Registrar that were not at the RNHaE’s request. (PEDNR Recommendation #4)
5. The registration agreement must include or point to any fee(s) charged for the postexpiration renewal of a domain name. If the Registrar operates a website for registration or renewal, it should state, both at the time of registration and in a clear place on its website, any fee(s) charged for the post-expiration renewal of a domain name or the recovery of a domain name during the Redemption Grace Period. (PEDNR Recommendation #5)
6. The registration agreement and Registrar web site (if one is used) must clearly indicate what methods will be used to deliver pre- and post-expiration notifications, or must point to the location where such information can be found. What destination address/number will be used must also be specified, if applicable. (PEDNR Recommendation #6)
7. Registrar must notify Registered Name Holder of impending expiration no less than two times. One such notice must be sent one month or 30 days prior to expiration (±4 days) and one must be sent one week prior to expiration (±3 days). If more that two alert notifications are sent, the timing of two of them must be comparable to the timings specified. (PEDNR Recommendation #7)
8. Unless the Registered Name is renewed or deleted by the Registrar, at least one notification to the RNHaE, which includes renewal instructions, must be sent after expiration. (PEDNR Recommendation #8)
9. Notifications of impending expiration must include method(s) that do not require explicit registrant action other than standard e-mail receipt in order to receive such notifications. (Recommendation #9)
10. With the exception of sponsored2 gTLDs, all gTLD Registries shall offer the Redemption Grace Period (RGP). For currently existing unsponsored gTLDs that do not currently offer the RGP, a transition period shall be allowed. All new gTLDs must offer the RGP. As part of the implementation, ICANN Staff should consider the Technical Steering Group's Implementation Proposal (see http://www.icann.org/en/ meetings/bucharest/redemption-topic.htm) (PEDNR Recommendation #13)
2 An unsponsored TLD operates under policies established by the global Internet community directly through the ICANN process, while a sponsored TLD is a specialized TLD that has a sponsor representing the narrower community that is most affected by the TLD. It should be noted that this distinction is no longer used in the new gTLD program.
11. If a Registrar offers registrations in a gTLD that supports the RGP, the Registrar must allow the Registered Name Holder at Expiration to redeem the Registered Name after it has entered RGP. (PEDNR Recommendation #14)
12. A transfer of a domain name during the RGP should not be allowed. (PEDNR Recommendation #15)
13. In the event that ICANN gives reasonable notice to Registrars that ICANN has published web content as described in PEDNR Recommendation #16:
§ Registrars, who have a web presence, must provide a link to the ICANN content on any website it may operate for domain name registration or renewal clearly displayed to its Registered Name Holders at least as clearly as its links to policies or notifications required to be displayed under ICANN Consensus Policies.
§ Registrars may also host similar material adapted to their specific practices and processes.
§ Registrar must point to the ICANN material in a communication sent to the registrant immediately following initial registration as well as in the mandated annual WHOIS reminder. (PEDNR Recommendation #17)
Note: Some of these recommendations may need special consideration in the context of existing provisions in the Uniform Dispute Resolution Policy (UDRP), the proposed Uniform Rapid Suspension System (URS) or exceptions due to fraud, breach of registration agreement or other substantive reasons and the GNSO Council, therefore, recommends that such considerations are taken into account as part of the implementation of these recommendations, once adopted.
(B)
The GNSO Council recommends the following best practices for promotion by ICANN and the Registrar Stakeholder Group:
• If post-expiration notifications are normally sent to a point of contact using the domain in question, and delivery is known to have been interrupted by postexpiration actions, post-expiration notifications should be sent to some other contact point associated with the registrant if one exists. (PEDNR Recommendation #10)
• The notification method explanation (see recommendation #9) should include the registrar’s email address from which notification messages are sent and a suggestion that registrants save this email address as a ‘safe sender’ to avoid notification emails being blocked by spam filter software. (PEDNR Recommendation #11)
• Registrars should advise registrants to provide a secondary email point of contact that is not associated with the domain name itself so that in case of expiration reminders can be delivered to this secondary email point of contact. (PEDNR Recommendation #12)
(C)
The GNSO Council recommends that ICANN, in consultation with Registrars, ALAC and other interested parties, will develop educational materials about how to properly steward a domain name and how to prevent unintended loss. Such material may include registrant responsibilities and the gTLD domain life-cycle and guidelines for keeping domain name records current. (PEDNR Recommendation #16).
(D)
ICANN Compliance is requested to provide updates to the GNSO Council on a regular basis in relation to the implementation and effectiveness of the proposed recommendations, either in the form of a report that details amongst others the number of complaints received in relation to renewal and/or post-expiration related matters or in the form of audits that assess if the policy has been implemented as intended. (PEDNR Recommendation #18)
(E)
The GNSO Council shall convene a PEDNR Implementation Review Team to assist ICANN Staff in developing the implementation details for the new policy should it be approved by the ICANN Board. The Implementation Review Team will be tasked with evaluating the proposed implementation of the policy recommendations as approved by the Board and is expected to work with ICANN Staff to ensure that the resultant implementation meets the letter and intent of the approved policy. If the PEDNR Implementation Review Team identifies any potential modifications to the policy or new PEDNR policy recommendations, the PEDNR Implementation Review Team shall refer these to the GNSO Council for its consideration and follow-up, as appropriate. Following adoption by the ICANN Board of the recommendations, the GNSO Secretariat is authorized to issue a call for volunteers for a PEDNR Implementation Review Team to the members of the PEDNR Working Group.
4. Motion regarding Public Comments on the Policy Development Process Work Team Final Report
Made by: Jeff Neuman
Seconded by: Carlos Aguirre
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://gnso.icann.org/issues/pdp-wt-final-report-final-31may11-en.pdf) on 1 June 2011 to the GNSO Council;
WHEREAS the GNSO Council opened a 30-day public comment period on the Final Report (see http://www.icann.org/en/announcements/announcement-2-09jun11-en.htm);
WHEREAS ICANN Staff produced a Summary and Analysis document of the comments received and posted it at
http://www.icann.org/en/public-comment/report-comments-pdp-final-report-11jul11-en.pdf
NOW THEREFORE, BE IT:
RESOLVED, the GNSO Council directs the PDP-WT to review the Summary and Analysis document as well as the comments and make any changes to the PDP-WT Final Report as deemed appropriate. The PDP-WT should submit the updated version of the Final Report to the GNSO Council as soon as possible, preferably in time for consideration at its next meeting on 8 September.
5. Motion to Address the Remaining Registration Abuse Policies Working Group Recommendations
(For discussion only)
Whereas the Registration Abuse Policies (RAP) Working Group submitted its report to the GNSO Council on 29 May 2010 (see http://gnso.icann.org/issues/rap/rap-wg-final-report-29may10-en.pdf);
Whereas the GNSO Council reviewed the report and its recommendations and decided to form an implementation drafting team to draft a proposed approach with regard to the recommendations contained in the Registration Abuse Policies Working Group Final Report;
Whereas the Registration Abuse Policies Implementation Drafting Team submitted its proposed response to the GNSO Council on 15 November 2010 (see http://gnso.icann.org/correspondence/rap-idt-to-gnso-council-15nov10-en.pdf);
Whereas the GNSO Council considered the proposed approached at its Working Session at the ICANN meeting in Cartagena;
Whereas the GNSO Council acted on a number of RAP recommendations at its meeting on 3 February 2011 (see http://gnso.icann.org/resolutions/#201102);
Whereas the GNSO Council requested feedback from ICANN Compliance in relation to WHOIS Access recommendation #2 and Fake Renewal Notices recommendation #1 and a response was received on 23 February 2011 (http://gnso.icann.org/mailing-lists/archives/council/msg10766.html). In addition, a discussion with Compliance Staff was held at the ICANN meeting in San Francisco.
Whereas the GNSO Council considered the remaining RAP recommendations in further detail during its working session at the ICANN meeting in Singapore based on an overview prepared by ICANN Staff (see http://gnso.icann.org/correspondence/overview-rapwg-recommendations-18may11-en.pdf).
NOW THEREFORE BE IT:
RESOLVED, the GNSO Council thanks the ICANN Compliance Department for its feedback in relation to WHOIS Access recommendation #2 and determines that no further work on this recommendation is needed.
RESOLVED, the GNSO Council thanks the ICANN Compliance Department for its feedback in relation to Fake Renewal Notices recommendation #1 and determines that no further work on this recommendation is needed.
RESOLVED, the GNSO Council determines that additional information is needed from the Registrar Stakeholder Group with regard to the conditional Fake Renewal Notices recommendation #2 before an Issue Report should be requested of Staff. The GNSO Council hereby requests that the Registrar Stakeholder Group provide further information and data on the nature and scope of the issue of Fake Renewal Notices to help inform the GNSO Council’s deliberations on whether an Issue Report should be requested.
RESOLVED, in response to WHOIS Access recommendation #1, the GNSO Council acknowledges receipt of this recommendation and determines to defer its consideration until the results of the WHOIS studies that are currently being undertaken are available. At that time, the GNSO Council intends to consider the appropriate next steps in relation to WHOIS access recommendation #1 in light of the data obtained from these WHOIS studies.
RESOLVED, with regard to the recommendation on Meta Issue: Collection and Dissemination of Best Practices, the GNSO Council acknowledges receipt of this recommendation and determines to defer its consideration until it evaluates the outcome of Malicious Use of Domain Names recommendation #1, which aims to develop best practices to help registrars and registries address the illicit use of domain names. In light of the pending request to Staff to develop a Discussion Paper on the Malicious Use of Domain Names, the GNSO Council believes that the upcoming review and analysis of this Discussion Paper may serve to inform the Council of the issues related to the Meta Issue: Collection and Dissemination of Best Practices recommendation.
RESOLVED, in regard to the recommendations on cross-TLD Registration Scam and Domain Kiting/Tasting, the GNSO Council Chair shall communicate to the Security and Stability Advisory Committee (SSAC) the findings of the RAP WG in this regard and request that the SSAC consider evaluating and/or monitoring these abuses. If the SSAC elects to conduct this work, the GNSO Council requests that the SSAC inform the GNSO Council if it believes that further policy work by the GNSO Council should be undertaken to address these two types of abuse. In addition, the GNSO Council suggests that the issue of cross-TLD registration scam be included in the agenda of its next meeting with the ccNSO Council since this type of abuse may also affect ccTLDs.
RESOLVED, in response to the recommendation on Meta Issue: Uniformity of Reporting, the GNSO Council acknowledges receipt of this recommendation, and hereby requests feedback from ICANN Compliance Department on whether improvements / changes have been made since the RAPWG Report or are foreseen in the near future to facilitate reporting and tracking of violations and/or complaints. Further consideration of this Meta Issue is deferred pending receipt of such information from the ICANN Compliance Department.
RESOLVED, in response to the recommendations on Uniformity of Contracts; Gripe Sites, Deceptive and/or Offensive Domain Names recommendation #2, and; Cybersquatting recommendation #2, since the RAPWG did not achieve consensus on these recommendations, the GNSO Council declines to undertake further policy work on these recommendations at this time.
RESOLVED, in response to Gripe Sites; Deceptive and/or Offensive Domain Names recommendation #1, the GNSO Council acknowledges receipt of this recommendation, and agrees with the RAPWG that no further action is called for at this time.
