ICANN ICANN Email List Archives


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

[gnso-irtp-b-jun09] RE: For your review - Updated proposals recommendation #8 and #9

  • To: Marika Konings <marika.konings@xxxxxxxxx>, "Gnso-irtp-b-jun09@xxxxxxxxx" <Gnso-irtp-b-jun09@xxxxxxxxx>
  • Subject: [gnso-irtp-b-jun09] RE: For your review - Updated proposals recommendation #8 and #9
  • From: "Sedo :: Simonetta Batteiger" <simonetta@xxxxxxxx>
  • Date: Wed, 12 Oct 2011 17:41:48 +0200

Hi Marika,

On #8: would think that a) is nice because ICANN has control over adding 
explanations that will then update for all registrars automatically (without 
everyone having to make updates themselves which takes time and will probably 
never be something everyone will comply with at the same time).

On #9: I think it would be important to qualify that "legal requirements" are 
defined as something other than the registrar's own T&C - I assume this was 
supposed to refer to court orders, subpoenas, etc... Otherwise a registrar 
could just put something in their T&Cs stating that they reserve the right to 
not remove a lock at their own discretion and you agree to that as long as you 
register with them... (which is NOT what the working group's intentions were).


From: owner-gnso-irtp-b-jun09@xxxxxxxxx 
[mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Marika Konings
Sent: Wednesday, October 12, 2011 5:16 AM
To: Gnso-irtp-b-jun09@xxxxxxxxx
Subject: [gnso-irtp-b-jun09] For your review - Updated proposals recommendation 
#8 and #9

Dear All,

As a result of our meeting on 27 September, two issues were raised with regard 
to the IRTP Part B Staff Proposals.

IRTP Part B recommendation #8 (Whois Status Messages)
Issue: the concern was expressed that some registrars have used Whois output to 
include advertising in the form of hyperlinks and as a result many registrars 
block the display of hyperlinks in Whois output. How would this affect the 
Staff proposal to use a hyperlink to direct people to the web page where the 
information on the status values will be located?
Response: The Staff proposal puts forward two options a) require registrars to 
include an hyperlink to an ICANN web-page where the different status are 
explained in their Whois output; b) require registrars to include the status 
explanation directly in their Whois output. The concern regarding registrars 
removing hyperlinks from Whois output could be mitigated by amending option a) 
to require registrars to not remove ICANN hyperlinks (or particularly the ICANN 
status hyperlinks), in addition to including a sentence directing people to the 
Internic web-site. The implementation of both options a) and b) will require 
some efforts on the part of the registrars, but even with the addition to 
option a), neither of them is expected to require substantial effort or 
investment. The advantage of option a) is that the explanation of the status 
can evolve over time as need be without the registrars having to make any 
changes to their systems, which is not the case with option b). (see updated 
proposal attached)

IRTP Part B recommendation #9 (Locking and unlocking of domain names):
Issue: Should additional language be added to clarify that valid legal concerns 
overrules the 'right' of a registrant to have the domain name unlocked within 5 
days? Everyone was clear that a transfer could, of course, still be denied if 
one of the reasons for denial would apply, but there was a desire to be able to 
maintain the lock if it was applied for valid reasons.
Response: To address this concern, Staff proposes to add the following language 
to the provision: 'The registrar may still be permitted or required to restrict 
some registration changes or transfers pursuant to the UDRP or other ICANN 
consensus policies or legal requirements'. (see updated proposal attached).

We hope that these modifications to the proposals address the WG's concerns. Of 
course, we look forward to receiving your feedback.

With best regards,


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

Privacy Policy | Terms of Service | Cookies Policy