Re: [gnso-irtp-b-jun09] Issue E

[Marika Konings <marika.konings@xxxxxxxxx>]

As a reminder, here is the information from the issues report on this matter.

With best regards,

Marika

>From the IRTP Part B Issues Report:

4.6       Clarification of denial reason #7

4.6.1    Issue E: Whether, and if so, how to best 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 (Recommendation from the IRTP Denials WG).

4.6.2.   From the Issues Report on Specified Inter-Registrar Transfer Policy 
Issues 
<http://gnso.icann.org/issues/transfers/issues-report-transfer-denial-clarifications-19oct07.pdf>
 :

 “The current language (describing a reason for which a registrar of record may 
deny a transfer request) reads: 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. Referring to the Task 
Force’s Report (http://www.icann.org/gnso/transfers-tf/report-exhd-12feb03.htm) 
for the intention behind the policy language, the following Q/A occurs:

9. "Some Registrars liberally employ the 'Registrar lock' function as it 
relates to the domain names they register for Registrants. This often means 
that Registrants *can’t* transfer their domain name in a predictable way. Do 
the Task Force recommendations consider this?"

A. Through extensive discussion within the Task Force and further consultation 
with the community after the Interim Report, the Task Force formed a minor 
series of amended recommendations that simply requires Registrars to provide 
Registrants with simple and transparent mechanisms by which Registrants can 
simply unlock or lock their domain name using accessible processes established 
by the Registrar.

Analysis: The Task Force heard this concern from several user groups. Earlier 
versions of this report contained substantially more stringent recommendations, 
however further discussion within the Task Force and outreach to various 
stakeholders within the DNSO only drew the lack of consensus on the older 
recommendations into focus. Accordingly the Task Force re-crafted its 
recommendations in order to support the principles that were supported by 
consensus.

In the current environment, registrar policies and practices vary with regard 
to means available to registrants for removing a Registrar Lock status. As a 
prerequisite to a registrar’s denial of a transfer request for this reason, the 
policy requires that registrars provide a “readily accessible and reasonable 
means for the Registered Name Holder to remove the lock status.” In staff’s 
investigation of complaints about an inability to unlock a name, it is 
necessary to review the circumstances on a case by case basis, and apply an 
interpretation as to whether the registrar’s practice is reasonable.

ICANN continues to receive complaints from registrants noting difficulty in 
unlocking names (see data from 2006 at 
http://www.icann.org/compliance/pie-problem-reports-2006.html).

ICANN could more efficiently enforce this provision if there were a test 
available for what is "reasonable or readily accessible." Adoption of a common 
test or standard would also facilitate uniform enforcement of this provision[1] 
<#_ftn1> .

In instances where a domain name is in Registrar Lock status, a transfer that 
is initiated by a potential gaining registrar will be automatically rejected at 
the registry level, without an explicit denial by the registrar of record. This 
makes it difficult for a registrar of record to comply with the requirement to 
provide the registrant and potential gaining registrar with the reason that the 
transfer was denied.  It may be helpful for the policy language to reflect the 
process that occurs in the case of this type of denial.”

4.6.3 Clarification of denial reason #7 was discussed in a previous PDP on 
Clarification of Denial Reasons, but the drafting group recommended dealing 
with this issue in  conjunction with the question of standards or best 
practices regarding use of Registrar Lock Status which has been outlined in the 
previous section. The drafting group noted in its report 
<http://gnso.icann.org/issues/transfers/gnso-final-draft-denial-reasons-04jun08.pdf>
  the following concerns:

-      “Discussions focused on clarification of the meaning of "readily 
accessible and reasonable means", but in the attempts to clarify this by 
comparison and by increased specificity potential undesired consequences were 
identified, see below

-      The proposed texts raise deeper issues and more complexity than we are 
prepared to deal with within the scope and timeframe allotted to this drafting 
group

-      We want to avoid a situation where registrars increase difficulty on 
contact/DNS changes in order to prevent transfers

-      Some registrars have offered higher levels of security, and don't want 
to lose the flexibility of offering those add-on opt-in services

-      The trade-off between security and convenience is one that must be made 
by registrants and this policy needs to provide the ability to make that choice

-      Issue 5 under PDP C of the IRTP Issues PDP Recommendations of 19 March 
2008 and the reason for wanting to clarify reason for denial number 7 are very 
closely related:

·       Issue 5 of PDP C on IRTP Operational Rule Enhancements states: "Whether 
standards or best practices should be implemented regarding use of Registrar 
Lock status (e.g., when it may/may not, should/should not be applied). (CR 8.0)"

·       The IRTP Policy Clarification of Reasons for Denial final report of 9 
April 2008 says in the first sentence of the second paragraph on page 5: 
"Regarding "lock status", there is support for clarification, with a clear 
focus on the meaning of "readily accessible and reasonable means" for removing 
the lock."

As a result, the GNSO Council resolved ‘that the work on denial reason #7 […] 
be suspended until such time as PDP C of the IRTP Issues PDP is initiated’.

[1] <#_ftnref>  As an example of such a test or standard, Section 5 of the 
policy includes the following in regard to provision of the authInfo code: 
“Registrars may not employ any mechanism for complying with a Registered Name 
Holder’s request to remove the lock status that is more restrictive than the 
mechanisms used for changing any aspect of the Registered Name Holder’s contact 
or name server information.”

On 27/07/10 17:16, "Mike O'Connor" <mike@xxxxxxxxxx> wrote:

hi all,

here's a series of paragraphs to kick off the Issue E discussion.

Denial Reason #7 (as currently writ)

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.

from the Initial Report

Prior to receipt of the transfer request, the domain name was locked pursuant 
to the Registrar’s published security policy or at the direction of the 
Registered Name Holder provided that the Registrar includes in its registration 
agreement the terms and conditions upon which it locks domains and further that 
the Registrar provides a readily accessible and reasonable means for the 
Registered Name Holder to remove the lock status. If the Registrar does not 
provide a means to allow a Registered Name Holder to remove the lock status 
themselves, then Registrar must facilitate removing the lock within 5 calendar 
days of receiving a request from the Registered Name Holder.

unpacked version of the Initial Report language (just a few punctuation marks 
and carriage returns)

Prior to receipt of the transfer request, the domain name was locked:

-- pursuant to the Registrar’s published security policy or at the direction of 
the Registered Name Holder,

-- provided that the Registrar includes in its registration agreement the terms 
and conditions upon which it locks domains, and

-- further that the Registrar provides a readily accessible and reasonable 
means for the Registered Name Holder to remove the lock status.

If the Registrar does not provide a means to allow a Registered Name Holder to 
remove the lock status themselves, then Registrar must facilitate removing the 
lock within 5 calendar days of receiving a request from the Registered Name 
Holder.


issues to puzzle through

-- should we limit this only to locks imposed by Registered Name Holders?  
Michael Collins suggested this, but my recollection is that this policy is 
really aimed at both registrant-initiated AND registrar-initiated locks.  so if 
we want, we can explore moving the treatment of registrar-initiated locks to 
Issue D, but i'll be grumpy about dropping it altogether.

-- how can we address Paul's point that overly-detailed "published security 
policies" provide a roadmap to the criminals?  my take is that this can be 
finessed by leaving the language as it's written -- which leaves Registrars a 
fair amount of latitude as to how detailed they make those published security 
policies.

-- is the 5-day interval the right one?  i don't have strong feelings about 
this -- but again, this might be made less complicated if we split the 
treatment of registrar-initiated and registrant-initiated locks.

there's my first pass.

have at it, peepul

mikey


- - - - - - - - -
phone 651-647-6109
fax  866-280-2356
web http://www.haven2.com
handle OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)