Sorry for the delay on this. The proposed amendment to cover the concerns raised at our public meeting in Sydney is to add the following paragraph directly after the questions a) through e): To inform its work, the WG should pursue the availability of further information from ICANN compliance Staff to understand how elements of the existing Inter-Registrar Transfer Policy that are applicable to the above questions are enforced. The WG should also request compliance Staff to review any policy recommendations it develops and provide advice on how the recommendations may best be structured to ensure clarity and enforceability. In addition, I made Avri's suggested amendment to the Working Group processes section by simply referring to the link on the Wiki. So that section now reads: Working Group processes: While the development of Guidelines for Working Group operations are still to be developed the guidelines at the following link will apply to this WG: https://st.icann.org/gnso-council/index.cgi?working_group_process The entire amended motion follows below. I have not updated the Wiki. Thanks, Tim ===================================== Motion – Approval of a Charter for the IRTP Part B WG Whereas On 24 June 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. To inform its work, the WG should pursue the availability of further information from ICANN compliance Staff to understand how elements of the existing Inter-Registrar Transfer Policy that are applicable to the above questions are enforced. The WG should also request compliance Staff to review any policy recommendations it develops and provide advice on how the recommendations may best be structured to ensure clarity and enforceability. Working Group processes: While the development of Guidelines for Working Group operations are still to be developed the guidelines at the following link will apply to this WG: https://st.icann.org/gnso-council/index.cgi?working_group_process 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