RE: [council] Motion on next round of IRTP issues to address

["Tim Ruiz" <tim@xxxxxxxxxxx>]

Makes sense. Accepted as friendly.

Tim 
 
  -------- Original Message --------
Subject: RE: [council] Motion on next round of IRTP issues to address
From: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
Date: Tue, April 14, 2009 1:46 pm
To: "Tim Ruiz" <tim@xxxxxxxxxxx>, "GNSO Council "
<council@xxxxxxxxxxxxxx>


Tim,

I would like to request what I think is a friendly amendment to this
motion.

Change the intro to the resolve section:

From: "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:"

To: "Pursuant to section 1.b of Annex A of ICANN's Bylaws, that the GNSO
Council requests the creation of an issues report on the following
issues:" 

The previous wording was accurate, but I am concerned that it could
easily be misunderstood to mean that we are initiating a PDP. As you
know, we are only requesting an issues report and once the issues report
is complete, we will decide whether to initiate a PDP. My rewording is
simply intended to avoid any confusion in this regard.

Chuck

> -----Original Message-----
> From: owner-council@xxxxxxxxxxxxxx 
> [mailto:owner-council@xxxxxxxxxxxxxx] On Behalf Of Tim Ruiz
> Sent: Wednesday, April 08, 2009 12:10 PM
> To: GNSO Council 
> Subject: [council] Motion on next round of IRTP issues to address
> 
> 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.p
> df; 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.)
> 
>