The IRTP Working Group has considered the issues contained in Part B and Part C for possible inclusion in the next round of work on the remaining IRTP issues. As a result, they have asked that I present the following motion (below in text, and attached in a Word doc): Tim WHEREAS, The Inter-Registrar Transfer Policy (IRTP) is an existing consensus policy under review by the GNSO, A GNSO group of volunteers assigned five PDP groupings to 19 identified IRTP issues, based on a previously developed prioritized issues list, Three additional issues were added to IRTP C based on recommendations from the IRTP Denial Definitions WG and the Issues Report on Post-Expiration Domain Name Recovery, The IRTP Part A WG has recommended combining the issues outlined under PDP B and some of the issues outlined under PDP C into one PDP B in order to be more efficient and hopefully reduce the overall timeline for addressing all the IRTP PDPs, The GNSO Council retains the option to address the issues outlined below in one PDP or two separate PDPs following the completion of the issues report, RESOLVED, Pursuant to section 1.b of Annex A of ICANN's Bylaws, that the GNSO Council initiate the formal GNSO Policy Development Process by requesting the creation of an issues report on the following issues: 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). (Issue #2) b) Whether additional provisions on undoing inappropriate transfers are needed, especially with regard to disputes between a Registrant and Admin Contact. The policy is clear that the Registrant can overrule the AC, but how this is implemented is currently at the discretion of the registrar. (Issue #7) c) Whether special provisions are needed for a change of registrant near a change of registrar. The policy does not currently deal with change of registrant, which often figures in hijacking cases. (Issue #9) d) Whether standards or best practices should be implemented regarding use of Registrar Lock status (e.g., when it may/may not, should/should not be applied). (Issue #5) 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. (Recommendation from the IRTP Denials WG) (Note: The issue numbers included above refer to the original numbering in the Transfers Working Group list.)