ICANN ICANN Email List Archives

[gnso-irtp-b-jun09]


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

RE: [gnso-irtp-b-jun09] Feedback on Charter Question E

  • To: <rob.golding@xxxxxxxxxxxxxxx>, <Gnso-irtp-b-jun09@xxxxxxxxx>
  • Subject: RE: [gnso-irtp-b-jun09] Feedback on Charter Question E
  • From: "Diaz, Paul" <pdiaz@xxxxxxxxxxxxxxxxxxxx>
  • Date: Mon, 23 Aug 2010 09:19:07 -0400

I support Rob's point.  This WG needs to be ever-vigilant about not
creating "unintended consequences" - especially in matters of domain
name security.  Abolishing Denial Reason #7 likely would have the effect
of negating the enhanced security offered by some Registry Operators'
registry lock services.  I don't think that's what anyone intends...

If members of the WG really believe that Denial Reason #7 needs
clarification, perhaps the following extra text (in CAPS) will help?

A domain name was already in AN EPP-CONSISTENT "lock status" provided
that the Registrar provides a readily accessible and reasonable means
for the Registered Name Holder to remove the lock status.

Regards, P

-----Original Message-----
From: owner-gnso-irtp-b-jun09@xxxxxxxxx
[mailto:owner-gnso-irtp-b-jun09@xxxxxxxxx] On Behalf Of Rob Golding
Sent: Monday, August 23, 2010 8:54 AM
To: 'Marika Konings'; Gnso-irtp-b-jun09@xxxxxxxxx
Subject: RE: [gnso-irtp-b-jun09] Feedback on Charter Question E


> 2.    Denial reason #7 - this seems superfluous as a ground for
denying
> a transfer request. If a domain is in "lock status", the registry
> cannot initiate a transfer request (so there will not be a ground for
> denial based on #7)

That applies where the "lock" is one set by/at the registry, rather than
additional lock-levels that some of us registrars offer our clients.

If one of our registrants request their domain is "super-locked" then
all
attempts at transfer will be automatically denied, until the registrant
decides to remove that restriction - it's one of the ways the management
of
a business stop "upstart" in their IT department moving their domains
around
without authorisation.

Regards,
Rob





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

Privacy Policy | Terms of Service | Cookies Policy