ICANN/GNSO GNSO Email List Archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

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

  • To: "Marika Konings" <marika.konings@xxxxxxxxx>
  • Subject: RE: [council] Motion on next round of IRTP issues to address
  • From: "Tim Ruiz" <tim@xxxxxxxxxxx>
  • Date: Wed, 15 Apr 2009 13:02:16 -0700
  • Cc: "GNSO Council " <council@xxxxxxxxxxxxxx>
  • List-id: council@xxxxxxxxxxxxxx
  • Reply-to: "Tim Ruiz" <tim@xxxxxxxxxxx>
  • Sender: owner-council@xxxxxxxxxxxxxx
  • User-agent: Web-Based Email 5.0.9

Marika,

I am in agreement with a 30-day period to prepare the report. Not sure
if I can accept that as a friendly amendment but I think so. Either way,
I will support the longer period. The clarification to the note also
makes sense.

Thanks,
Tim  
 
-------- Original Message --------
Subject: RE: [council] Motion on next round of IRTP issues to address
From: Marika Konings <marika.konings@xxxxxxxxx>
Date: Wed, April 15, 2009 1:26 pm
To: Tim Ruiz <tim@xxxxxxxxxxx>, "GNSO Council "
<council@xxxxxxxxxxxxxx>

Dear All,

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.

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´.

With best regards,

Marika
________________________________________
From: owner-council@xxxxxxxxxxxxxx [owner-council@xxxxxxxxxxxxxx] On
Behalf Of Tim Ruiz [tim@xxxxxxxxxxx]
Sent: Wednesday, April 08, 2009 18:10
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.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.)





<<< Chronological Index >>>    <<< Thread Index >>>