This charter is based on the GNSO Council decision to create a PDP WG to recommend best practices and/or consensus policies regarding the issues defined in the Post-Expiration Domain Name Recovery Issues Report at:
http://gnso.icann.org/issues/post-expiration-recovery/report-05dec08.pdf The full resolution of the Council on 7 May 2009: Whereas on 05 December 2008, the GNSO received an Issues Report on Post-Expiration Domain Name Recovery (PEDNR); Whereas on 29 January 2009 the GNSO Council decided to form a Drafting Team (DT) to consider the form of policy development action in regard to PEDNR; Whereas a DT has formed and its members have discussed and reviewed the issues documented in the Issues Report; Whereas the DT has concluded that although some further information gathering may be needed, it should be done under the auspices of a PDP; Whereas staff has suggested and the DT concurs that the issue of registrar transfer during the RGP might be better handled during the IRTP Part C PDP. The GNSO Council RESOLVES To initiate a Policy Development Process (PDP) to address the issues identified in the Post-Expiration Domain Name Recovery Issues Report. The charter for this PDP should instruct the Working Group: that it should consider recommendations for best practices as well as or instead of recommendations for Consensus Policy; that to inform its work it should pursue the availability of further information from ICANN compliance staff to understand how current RAA provisions and consensus policies regarding deletion, auto-renewal, and recovery of domain names during the RGP are enforced; and that it should specifically consider the following questions: - Whether adequate opportunity exists for registrants to redeem their expired domain names;
- Whether expiration-related provisions in typical registration agreements are clear and conspicuous enough;
- Whether adequate notice exists to alert registrants of upcoming expirations;
- 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).
- Whether to allow the transfer of a domain name during the RGP. The GNSO Council further resolves that the issue of logistics of possible registrar transfer during the RGP shall be incorporated into the charter of the IRTP Part C charter. Charter Whereas: The GNSO council has decided to initiate a PDP on Post-Expiration Domain Name Recovery (PEDNR); and The GNSO council had decided against initiating a Task force as defined in the bylaw; The GNSO Council RESOLVES To form a Working Group composed of Constituency representatives as well as interested stakeholders in order to develop potential policy and/or best practices to address the issues covered, while seeking additional information as appropriate to inform the work. The WG will also be open to invited experts and to members or representatives of the ICANN Advisory Committees, whether acting in their own right or as representatives of their AC. The Working Group initially shall: - Pursue the availability of further information from ICANN compliance staff to understand how current RAA provisions and consensus policies regarding deletion, auto-renewal, and recovery of domain names following expiration are enforced;
- Review and understand the current domain name life cycle;
- Review current registrar practices regarding domain name expiration, renewal, and post-expiration recovery.
The Working Group shall then consider the following questions: - Whether adequate opportunity exists for registrants to redeem their expired domain names;
- Whether expiration-related provisions in typical registration agreements are clear and conspicuous enough;
- Whether adequate notice exists to alert registrants of upcoming expirations;
- 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);
- Whether to allow the transfer of a domain name during the RGP.
The Working Group is expected to organize an issue update / workshop at the Seoul meeting, in addition to an update to the GNSO Council. The Working Group should consider recommendations for best practices as well as or instead of recommendations for Consensus Policy. Working Group processes: While the development of Guidelines for Working Group operations are still to be developed the following guidelines will apply to this WG: - The WG shall function on the basis of rough consensus, meaning all points of view will be discussed until the chair can ascertain that the point of view is understood and has been covered. Consensus views should include the names and affiliations of those in agreement with that view. Anyone with a minority view will be invited to include a discussion in the WG report. Minority report should include the names and affiliations of those contributing to the minority report.
- In producing the WG report, the chair will be responsible for designating each position as having one of the following designations:
- Unanimous consensus position
- Rough consensus position - a position where a small minority disagrees but most agree
- Strong support but significant opposition
- Minority viewpoint(s)
- If several participants in a WG disagree with the designation given to a position by the chair or any other rough consensus call, they can follow these steps sequentially:
- Send email to the chair, copying the WG explaining why the decision is believed to be in error.
- If the chair still disagrees, forward the appeal to the council liaison(s) to the group. The chair must explain his or her reasoning in the response. * If the liaisons support the chair's position, forward the appeal to the council. The liaison(s) must explain his or her reasoning in the response.
- If the council supports the chair and liaison's position, attach a statement of the appeal to the board report. This statement should include all of the documentation from all steps in the appeals process and should include a statement from the council.
- The chair, in consultation with the GNSO council liaison(s) is empowered to restrict the participation of someone who seriously disrupts the WG. Any such restriction will be reviewed by the GNSO council. Generally the participant should first be warned privately, and then warned publicly before such a restriction is put into place. In extreme circumstances this requirement may be bypassed.
- The WG will have an archived mailing list. The mailing list will be open for reading by the community. All WG meetings will be recorded and all recordings will be available to the public. A PEDNR WG mailing list has been created ( gnso-pednr-dt@icann.org ) with public archives at: http://forum.icann.org/lists/gnso-pednr-dt/.
- A SocialText wiki has been provided for WG usage and can be found at https://st.icann.org/post-expiration-dn-recovery-wg/index.cgi?post_expiration_domain_name_recovery_wg
- If the guidelines for WG processes change during the course of the WG, the WG may continue to work under the guidelines active at the time it was (re)chartered or use the new guidelines.
- The council liaisons to the WG will be asked to report on the WG status monthly to the council.
- All WG charters must be reviewed by the GNSO council every 6 months for renewal.
Milestones (dates to be updated if/when charter is approved) - WG formed, chair & Council liaison & staff coordinator identified = T
- Initial Report: T + 150 - 170 days
- First comment period ends: T + 170 - 200 days
- Preliminary Final Report: T + 190 - 220 days.
Note: If the WG decides that a change is needed to the milestone dates, it should submit a revised time line to the GNSO council for approval |