[council] GNSO Council resolutions 21 July 2011

[Glen de Saint Géry <Glen@xxxxxxxxx>]

Dear All,



Ahead of the official Council minutes, the following motions carried 
unanimously at the GNSO Council meeting on Thursday, 21 July 2011.



Please let me know if you have any questions.



Thank you.

Kind regards,



Glen





1.     Motion to extend the mandate of the Joint ccNSO/GNSO IDN Working Group 
(JIG)



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.



2.    Motion on the Adoption of the PEDNR Final Report and Recommendations

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 1, 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.


3.    Motion regarding Public Comments on the Policy Development Process Work 
Team Final Report


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 meeting in October 2011.







Glen de Saint Géry

GNSO Secretariat

gnso.secretariat@xxxxxxxxxxxxxx

http://gnso.icann.org