Post Expiration Domain Name Recovery (8:30 - 9:00)

Post-Expiration Domain Name Recovery - PDP Working Group Charter

Motion made by: Tim Ruiz
Seconded by: Chuck Gomes

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, andrecovery 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 thatonce 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:

1. 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;
2. Review and understand the current domain name life cycle;
3. Review current registrar practices regarding domain name expiration, renewal, and post-expiration recovery.

The Working Group shall then consider the following 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.

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 :1. Send email to the chair, copying the WG explaining why the decision is believed to be in error.
    2. 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.
    3. 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.
  • 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 itwas (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

IRTP Part B (9:00 - 9:30)

Motion I – Initiation of a PDP on IRTP Part B

Motion by: Tim Ruiz
Seconded: Chuck Gomes

Whereas:

The Inter-Registrar Transfer Policy (IRTP) is an existing consensus policy under review by the GNSO,

The GNSO Transfers Working Group identified a number of issues in its review of the current Policy and those issues have been grouped into suggested PDPs, set A-E, as per the Council's resolution of 8 May 2008,

The GNSO Council, in order to be more efficient and hopefully reduce the overall timeline for addressing all the IRTP PDPs, resolved on 16 April 2009 to combine the issues outlined under the original issue set B, addressing three issues on undoing IRTP transfers, and some of the issues outlined in issue set C, related to registrar lock status into one IRTP Part B,

The GNSO Issues Report Inter-Registrar Transfer Policy Part B was submitted to the GNSO Council on 15 May 2009,

The Issues Report recommends that the GNSO Council proceed with a Policy Development Process limited to consideration of the issues discussed in this report, and

The General Counsel of ICANN has indicated the topic is properly within the scope of the ICANN policy process and within the scope of the GNSO

Resolved

The GNSO will initiate a PDP on the issues defined in Inter Registrar Transfer Policy Issues Report Part B.

A Working Group will be created for the purpose of fulfilling the requirements of the PDP.

Motion II – Approval of a Charter for the IRTP Part B WG

Motion by: Tim Ruiz
Seconded: Chuck Gomes

Whereas
On (date) 2009 the GNSO Council initiated PDP IRTP Part B and, decided to create a PDP WG for the purposes of fulfilling the requirements of the PDP, and,

The GNSO Council has reviewed the charter.

Resolved
The GSNO Council approves the charter and appoints Tim Ruiz confirmed as the GNSO Council Liaison to the IRTP PDP Part B WG.

The GNSO council further directs that the work of the IRTP Part B WG be initiated no later then 14 days after the approval of this motion. Until such time as the WG can select a chair and that chair can be confirmed
by the GNSO Council, the GNSO council Liaison shall act as interim chair.

Charter
The Working Group shall consider the following questions as outlined in the issues report and make recommendations to the GNSO Council:
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.

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 :1. Send email to the chair, copying the WG explaining why the decision is believed to be in error.
    2. 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.
    3. 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 IRTP PDP B mailing list has been created (Gnso-irtp-b-jun09@icann.org) and the public archives are at http://gnso.icann.org/mailing-lists/.
  • A SocialText wiki has been provided for WG usage and can be found at https://st.icann.org/irtp-partb/index.cgi?irtp_part_b
  • 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 itwas (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

  • WG formed, chair & Council liaison & staff coordinator identified = T
  • Initial Report: T + 170 days
  • First comment period ends: T + 190 days
  • Preliminary Final Report: T + 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

IDNG Charter (09:30 - 10:00) (pending)

WHEREAS:

The ICANN community has been discussing issues related to IDN and IDN TLDs since 2000, and the ICANN board as early as September 2000 recognized "that it is important that the Internet evolve to be more accessible to those who do not use the ASCII character set";

There is expressed demand from the community, especially from language communities around the world who do not use English or a Latin based script as a primary language, including the CJK (Chinese Japanese Korean) communities and the right-to-left directional script communities (e.g. Arabic, Hebrew, Persian, etc.), for advancing the introduction of Internationalized Top-Level Domains (IDN TLDs);

GNSO IDN WG successfully completed its outcomes report in March 2007 and the GNSO Council approved the incorporation of its findings in the GNSO Final Report on the Introduction of New gTLDs in September 2007, describing policy requirements for the introduction of IDN gTLDs;

The community observes the successful development of the IDN ccTLD Fast Track based on the IDNC WG recommendations, and the ongoing progress for the Implementation of the IDN ccTLD Fast Track Process;

The implementation of the New gTLD process is ongoing and the schedule and development of the implementation should continue;

GNSO Council had made comments in response to the ccNSO-GAC Issues Report on IDN Issues, as well as in its comments on the IDNC WG Final Report expressed that “the introduction of IDN gTLDs or IDN ccTLDs should not be delayed because of lack of readiness of one category, but if they are not introduced at the same time, steps should be taken so that neither category is advantaged or disadvantaged, and procedures should be developed to avoid possible conflicts”;

GNSO Council made a resolution in January 2009 to assert that “the GNSO Council strongly believes that neither the New gTLD or ccTLD fast track process should result in IDN TLDs in the root before the other unless both the GNSO and ccNSO so agree”;

RESOLVED (TO BE DRAFTED):

  • initiate joint working group with ccNSO?
  • initiate GNSO working group?
  • request board to create a working group?
  • emphasize our position regarding introduction of new IDN TLDs?
  • All of the above in parallel?

    By-Law Changes (10:00 - 10:30)

Motion made by: Avri Doria
Seconded by: Chuck Gomes

Whereas

On 28 August 2008 the ICANN Board of Directors approved the BGC plan to restructuring of the GNSO; and

On 27 March 2009 the ICANN Policy Staff introduced a draft of proposed by-law changes related to the restructuring of the GNSO; and

Subsequent to receiving the changes suggested by the ICANN Policy Staff, the GNSO Council decided to create a Committee of the Whole to work on a proposed set of changes to the By-laws which committee was open to council members as well as substitutes from the constituencies and to representatives of applicant constituencies; and

On 8 June 2009 the Structural Improvements Committee of the Board Directors gave a set of clarification to questions posed by the GNSO Committee of the Whole; and

On 12 June 2009, the ICANN legal counsel gave a set of recommend edits to the GNSO Committee of the whole.

Resolved

The GNSO recommends to the ICANN Board of Directors that the By-laws related to the GNSO council be amended to read as documented in: (provisional GNSO Bylaws 6-22-09 Clean.doc )

  • No labels
For comments, suggestions, or technical support concerning this space, please email: ICANN Policy Department
© 2015 Internet Corporation For Assigned Names and Numbers