ICANN ICANN Email List Archives


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

[gnso-irtp-b-jun09] Your feedback requested - Programme for IRTP Part B brainstorming session

  • To: IRTP-A <Gnso-irtp-pdp-jun08@xxxxxxxxx>, "Gnso-irtp-b-jun09@xxxxxxxxx" <Gnso-irtp-b-jun09@xxxxxxxxx>
  • Subject: [gnso-irtp-b-jun09] Your feedback requested - Programme for IRTP Part B brainstorming session
  • From: Marika Konings <marika.konings@xxxxxxxxx>
  • Date: Thu, 4 Jun 2009 05:10:24 -0700

Dear All,

As you might be aware, an IRTP Part B brainstorming session has been scheduled 
for Sunday 21 June from 8.00 - 9.30 at the ICANN meeting in Sydney. In order to 
get the most value out of this session, I would be interested to receive your 
feedback on how to structure this meeting. My idea would be to start of with an 
overview of the IRTP Part B Issues report, followed by a discussion / 
brainstorming session on each of the issues outlined in this report. In order 
to facilitate this discussion, it might be helpful to get some volunteers to 
share their experiences or views on each or one of these. Below you will find 
an overview of the issues covered in IRTP Part B with some initial ideas for 
speakers / contributors. I am hoping that there might be some volunteers in the 
IRTP Part A WG. I look forward to receiving your feedback.

Best regards,


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> );

Overview by SSAC representative of recommendations of SSAC hijacking report

b)     Whether additional provisions on undoing inappropriate transfers are 
needed, especially with regard to disputes between a Registrant and Admin 
Contact (AC).

ICANN Compliance / Services staff to provide insight to how frequent this issue 

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;

Registrar representative

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 

Introduction to lock status by expert (?)
Registrar representative to talk about current practices and experiences

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.

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

Privacy Policy | Terms of Service | Cookies Policy