ICANN ICANN Email List Archives

[gnso-irtp-b-jun09]


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

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

  • To: "Diaz, Paul" <pdiaz@xxxxxxxxxxxxxxxxxxxx>
  • Subject: Re: [gnso-irtp-b-jun09] Feedback on Charter Question E
  • From: "Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>
  • Date: Mon, 30 Aug 2010 13:52:04 +0000


On 30 Aug 2010, at 14:47, Diaz, Paul wrote:

> I do not support Staff’s proposed amendment to Denial Reason #6 (below).  
> This is exactly the kind of “unintended consequence” that we need to guard 
> against.  If registrars were now only allowed to lock a domain once “the 
> informed consent of the registrant [had been] given on an opt-in basis,” it’s 
> quite likely that some domain holders will fail to do so and those names will 
> be more vulnerable to hijacking or theft.  

+1


>  
> This WG should be focused on clarifying the Transfer Policy’s terms to have a 
> lock REMOVED, not raising the bar against providing basic security in the 
> first place.

+1

>  
> Sincerely, P
>  
> From: Marika Konings [mailto:marika.konings@xxxxxxxxx] 
> Sent: Monday, August 30, 2010 4:36 AM
> To: Diaz, Paul; rob.golding@xxxxxxxxxxxxxxx; Gnso-irtp-b-jun09@xxxxxxxxx
> Subject: Re: [gnso-irtp-b-jun09] Feedback on Charter Question E
>  
> Dear All,
> 
> In response to the comments made by Paul and Rob, as we understand the 
> process, if a domain is "in an EPP consistent lock status", then it is not 
> possible to initiate a domain transfer, and therefore, it’s not possible to 
> deny such a transfer. Based on that, we suggested that the substance of 
> denial reason #7 (that registrars have to provide a reasonable means for 
> registrants to request the removal of any lock status) should be discussed 
> elsewhere in the policy and not included in the list of reasons why it's OK 
> for a registrar to deny a pending transfer request. (Of course, we might have 
> misunderstood how the process works, and if so, please feel free to clarify 
> or correct).
>  
> In addition, in relation to the discussions on Charter Question C and denial 
> reason #6, it might be beneficial to expand and clarify this language to 
> tailor it more to explicitly address registrar-specific (i.e. non-EPP) locks 
> in order to make it clear(er) that the registrant must give some sort of 
> informed opt-in express consent to having such a lock applied, and the 
> registrant must be able to have the lock removed upon reasonable notice and 
> authentication. This denial reason could potentially be split into two 
> reasons of registrant objection for denial -- (1) express objection to a 
> particular transfer, and (2) a general indefinite request to deny all 
> transfer requests. A proposed modification might be as follows:
>  
> "6. Express objection to the transfer from the Transfer Contact. Such 
> objection could take the form of a specific request made by the registrant to 
> deny a particular pending transfer request, or a general request made by the 
> registrant that the registrar temporarily or indefinitely deny all transfer 
> requests, but in either case the request from the registrant must be based on 
> the informed consent of the registrant given on an opt-in basis, and the 
> registrar must make available a reasonable and secure means for the 
> registrant to revoke the request on a timely basis, unilaterally and without 
> conditions."
> 
> With best regards,
> 
> Marika
> 
> On 23/08/10 15:19, "Diaz, Paul" <pdiaz@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > 
> > 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
> > 
> >

Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://blacknight.mobi/
http://mneylon.tel
Intl. +353 (0) 59  9183072
US: 213-233-1612 
UK: 0844 484 9361
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Twitter: http://twitter.com/mneylon

PS: Check out our latest offers on domains & hosting: http://domainoffers.me/
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845





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

Privacy Policy | Terms of Service | Cookies Policy