<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>RE: [council] Motion on next round of IRTP issues to address</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>I like the addition.<BR>
<BR>
Chuck<BR>
<BR>
<BR>
Sent from my GoodLink Wireless Handheld (www.good.com)<BR>
<BR>
-----Original Message-----<BR>
From: Marika Konings [<A HREF="mailto:marika.konings@icann.org">mailto:marika.konings@icann.org</A>]<BR>
Sent: Wednesday, April 15, 2009 02:33 PM Eastern Standard Time<BR>
To: Tim Ruiz; GNSO Council<BR>
Subject: RE: [council] Motion on next round of IRTP issues to address<BR>
<BR>
<BR>
Dear All,<BR>
<BR>
Based on the current workload, Staff would like to request the Council to consider a 30 day period to prepare the Issues Report, which would mean a deadline of 16 May.<BR>
<BR>
In addition, as a point of clarification, the Council might want to consider adding as a last sentence to the motion:´Issues a to c form the original PDP B, while issue d comes from the original PDP C´, so that the note at the end of the motion would read´Note: The issue numbers included above refer to the original numbering in the Transfers Working Group list. Issues a to c form the original PDP B, while issue d comes from the original PDP C´.<BR>
<BR>
With best regards,<BR>
<BR>
Marika<BR>
________________________________________<BR>
From: owner-council@gnso.icann.org [owner-council@gnso.icann.org] On Behalf Of Tim Ruiz [tim@godaddy.com]<BR>
Sent: Wednesday, April 08, 2009 18:10<BR>
To: GNSO Council<BR>
Subject: [council] Motion on next round of IRTP issues to address<BR>
<BR>
The IRTP Working Group has considered the issues contained in Part B and<BR>
Part C for possible inclusion in the next round of work on the remaining<BR>
IRTP issues. As a result, they have asked that I present the following<BR>
motion (below in text, and attached in a Word doc):<BR>
<BR>
Tim<BR>
<BR>
WHEREAS,<BR>
The Inter-Registrar Transfer Policy (IRTP) is an existing consensus<BR>
policy under review by the GNSO,<BR>
<BR>
A GNSO group of volunteers assigned five PDP groupings to 19 identified<BR>
IRTP issues, based on a previously developed prioritized issues list,<BR>
<BR>
Three additional issues were added to IRTP C based on recommendations<BR>
from the IRTP Denial Definitions WG and the Issues Report on<BR>
Post-Expiration Domain Name Recovery,<BR>
<BR>
The IRTP Part A WG has recommended combining the issues outlined under<BR>
PDP B and some of the issues outlined under PDP C into one PDP B in<BR>
order to be more efficient and hopefully reduce the overall timeline for<BR>
addressing all the IRTP PDPs,<BR>
<BR>
The GNSO Council retains the option to address the issues outlined below<BR>
in one PDP or two separate PDPs following the completion of the issues<BR>
report,<BR>
<BR>
RESOLVED,<BR>
Pursuant to section 1.b of Annex A of ICANN's Bylaws, that the GNSO<BR>
Council initiate the formal GNSO Policy Development Process by<BR>
requesting the creation of an issues report on the following issues:<BR>
<BR>
a) Whether a process for urgent return/resolution of a domain name<BR>
should be developed, as discussed within the SSAC hijacking report<BR>
(<A HREF="http://www.icann.org/announcements/hijacking-report-12jul05.pdf;">http://www.icann.org/announcements/hijacking-report-12jul05.pdf;</A> see<BR>
also <A HREF="http://www.icann.org/correspondence/cole-to-tonkin-14mar05.htm">http://www.icann.org/correspondence/cole-to-tonkin-14mar05.htm</A>).<BR>
(Issue #2)<BR>
b) Whether additional provisions on undoing inappropriate transfers are<BR>
needed, especially with regard to disputes between a Registrant and<BR>
Admin Contact. The policy is clear that the Registrant can overrule the<BR>
AC, but how this is implemented is currently at the discretion of the<BR>
registrar. (Issue #7)<BR>
c) Whether special provisions are needed for a change of registrant near<BR>
a change of registrar. The policy does not currently deal with change of<BR>
registrant, which often figures in hijacking cases. (Issue #9)<BR>
d) Whether standards or best practices should be implemented regarding<BR>
use of Registrar Lock status (e.g., when it may/may not, should/should<BR>
not be applied). (Issue #5)<BR>
e) Whether, and if so, how best to clarify denial reason #7: A domain<BR>
name was already in "lock status" provided that the Registrar provides a<BR>
readily accessible and reasonable means for the Registered Name Holder<BR>
to remove the lock status. (Recommendation from the IRTP Denials WG)<BR>
<BR>
(Note: The issue numbers included above refer to the original numbering<BR>
in the Transfers Working Group list.)<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>