MOTION TO APPROVE CROSS COMMUNITY WORKING GROUP PRINCIPLES
Made by: Jonathan Robinson
Seconded by: Jeff Neuman
Whereas, the GNSO from time to time has participated in cross-community working groups to address issues of common interest to other ICANN supporting organizations (SO) and advisory committees (AC);
Whereas, the GNSO Council desires to develop a GNSO agreed perspective with regard to the role, function and method of conducting joint activities for future projects that respects and preserves the recognized roles and responsibilities assigned to each SO/AC under the ICANN Bylaws;
Whereas, on 06 October 2011 the GNSO Council approved a charter and the formation of a Drafting Team to define a way forward for the effective chartering, functioning, and utilization of such cross-community working groups;
Whereas, on 04 January 2012 the Drafting Team provided to the Council for consideration Draft Principles for Cross-Community Working Groups: http://gnso.icann.org/drafts/draft-principles-for-cwgs-23dec11-en.pdf.
NOW THEREFORE, BE IT:
Resolved, that the GNSO Council hereby approves the Draft Principles for Cross-Community Working Groups for its own guidance and requests staff to disseminate them to the Chairs of the Supporting Organizations and Advisory Committees asking them to provide input to the GNSO Council in 60 days on both the principles themselves and the route forward for community-wide adoption or development of a related set of principles for the operation of Cross-Community Working Groups;
Resolved further, the GNSO Council thanks the Drafting Team members for their work in developing the Draft Principles and disbands the Team.
======================================================================
Motion on the Adoption of the Staff Proposal on IRTP Part B Recommendation #8
Made by: Mason Cole (as amended)
Seconded by: Jeff Neuman
Motion on the Adoption of the Staff Proposal on IRTP Part B Recommendation #8
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 in relation to recommendation #8, the GNSO Council resolved at its meeting on 22 June to request ‘ICANN staff to provide a proposal designed to ensure a technically feasible approach can be developed to meet this recommendation. Staff should take into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report). (IRTP Part B Recommendation #8). The goal of these changes is to clarify why the Lock has been applied and how it can be changed. Upon review of the proposed plan, the GNSO Council will consider whether to approve the recommendation’;
WHEREAS ICANN staff developed the proposal in consultation with the IRTP Part B Working Group which was put out for public comment (see http://www.icann.org/en/public-comment/irtp-b-staff-proposals-22nov11-en.htm);
WHEREAS comments were received from the Intellectual Property Constituency, and though received after the comment deadline were nonetheless considered by the GNSO Council, and and the proposal was submitted to the GNSO Council;
WHEREAS the GNSO Council has reviewed and discussed the ICANN Staff proposal in relation to IRTP Part B recommendation #8.
RESOLVED, the GNSO Council recommends to the ICANN Board of Directors that it adopts and implements IRTP Part B recommendation #8 and the related ICANN Staff proposal (as described in http://gnso.icann.org/issues/transfers/irtp-b-final-report-30may11-en.pdf and http://gnso.icann.org/mailing-lists/archives/council/msg12545.html).
==============
Motion on the Adoption of the Staff Proposal on IRTP Part B Recommendation #9 part 2
Made by: Mason Cole (as amended)
Seconded by: Jeff Neuman
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 in relation to recommendation #9 part b, the GNSO Council resolved at its meeting on 22 June to request ICANN Staff to provide a proposal for a new provision on locking / unlocking of a domain name, taking into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report - (Recommendation #9 - part 2). Upon review of the proposal, the GNSO Council will consider whether to approve the recommendation;
WHEREAS ICANN staff developed the proposal in consultation with the IRTP Part B Working Group which was put out for public comment (see http://www.icann.org/en/public-comment/irtp-b-staff-proposals-22nov11-en.htm);
WHEREAS comments were received from the Intellectual Property Constituency, and though received after the comment deadline were nonetheless considered by the GNSO Council, and and the proposal was submitted to the GNSO Council;
WHEREAS the GNSO Council has reviewed and discussed the ICANN Staff proposal in relation to IRTP Part B recommendation #9 part 2.
RESOLVED, the GNSO Council recommends to the ICANN Board of Directors that it adopts and implements IRTP Part B recommendation #9 part 2 and the related ICANN Staff proposal (as described in http://gnso.icann.org/issues/transfers/irtp-b-final-report-30may11-en.pdf and http://gnso.icann.org/mailing-lists/archives/council/msg12545.html).
==============
