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

["Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>]

On 30 Aug 2010, at 19:57, James M. Bladel wrote:

> Agree.  Locking a name when it is in a "steady state" is common among
> registrars, and considered a Best Practice against accidental or
> fraudulent changes or transfers.  Having millions of domain
> registrations that are "unlocked" by default is a concerning prospect.
> 
> Instead, I recommend we keep the focus on (1) registrant awareness of
> locks (no "double-secret" locks) and (2) their ability to expressly
> remove it in a timely manner.  
> 
> Also, I have an issue with the phrase "EPP-Consistent," as technical
> protocols may change or be renamed, and shouldn't be baked in to policy.
> Imagine if the first IRTP referenced "RRP-Consistent" locks!  I
> understand the intent, but think we should re-phrase.
> 
> 
> Finally, I'm still not convinced that all of this needs to be explicitly
> included in the IRTP itself. We should consider other ways to
> communicate this to all parties, such as a definitions sheet or
> Advisory.

How does one go about drafting an advisory? Where do these come from?


> 
> Thanks--
> 
> J.
> 
> 
> 
> 
> -------- Original Message --------
> Subject: Re: [gnso-irtp-b-jun09] Feedback on Charter Question E
> From: "Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>
> Date: Mon, August 30, 2010 8:52 am
> To: "Diaz, Paul" <pdiaz@xxxxxxxxxxxxxxxxxxxx>
> Cc: "<Gnso-irtp-b-jun09@xxxxxxxxx>" <Gnso-irtp-b-jun09@xxxxxxxxx>, 
> Marika Konings <marika.konings@xxxxxxxxx>
> 
> 
> 
> 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
> 

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
Direct Dial: +353 (0)59 9183090
Fax. +353 (0) 1 4811 763
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845