ICANN ICANN Email List Archives

[gnso-pednr-dt]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-pednr-dt] GNSO Council resolutions 21 July 2011

  • To: Glen de Saint Géry <Glen@xxxxxxxxx>
  • Subject: Re: [gnso-pednr-dt] GNSO Council resolutions 21 July 2011
  • From: Cheryl Langdon-Orr <langdonorr@xxxxxxxxx>
  • Date: Fri, 22 Jul 2011 00:06:19 +1000

:-)


Thanks for letting us know  Glen...



Cheryl Langdon-Orr
(CLO)



On 21 July 2011 23:57, Glen de Saint Géry <Glen@xxxxxxxxx> wrote:

> FYI
>
> 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****
>
> ** **
>
> ** **
>
> ** **
>


<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy