[gnso-irtp-b-jun09] Lock status information

[Marika Konings <marika.konings@xxxxxxxxx>]

As discussed on our call yesterday, please find below the excerpt from the IRTP 
Part B Issues Report related to charter question D - ‘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)’. In addition, 
you will find below the relevant section of the public comment received from 
Patrick Mevzek in relation to this issue.

With best regards,

Marika

=======================

Excerpt from the IRTP Part B Issues Report:

4.5            Standards or best practices regarding use of Registrar Lock 
Status

4.5.1            Issue D: 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) (Issue #5).

4.5.2            Registrar-Lock is described in RFC 2832 
<http://tools.ietf.org/html/rfc2832>  as:

“REGISTRAR-LOCK: The registrar of the domain sets the domain to this status. 
The domain cannot be modified or deleted when in this status. The registrar 
MUST remove REGISTRAR-LOCK status to modify the domain. The domain can be 
renewed. The domain SHALL be included in the zone file when in this status”.

Registrar-Lock does not refer to any internal flag or status termed ‘lock’ 
which a registrar may be using. As outlined in an ICANN Inter-Registrar 
Transfer Policy: Implementation Update 
<http://www.icann.org/en/announcements/announcement-21sep04-2.htm>  “Registrars 
will […] be able to use "registrar-lock" to give registrants added assurance 
that their domains will not be transferred or modified without their consent, 
but only if the registrar provides a readily accessible and reasonable means 
for registrants to remove the lock if and when the registrant decides to 
transfer”.

4.5.3            The Staff Report to the GNSO Council: Experiences with the 
Inter-Registrar Transfer Policy 
<http://www.icann.org/en/transfers/transfer-report-14apr05.pdf>  (14 April 
2005) noted that “many comments raised issues concerning locking mechanisms 
which are currently used by registrars. Variations in the use of lock statuses 
and their variability across registrars has added a level of complexity to the 
transfer process that in some cases has the effect of obstructing the desired 
ease of inter-registrar transfers. Additionally, such mechanisms impose a 
further burden on policy implementation because many registrants do not 
understand locking mechanisms. This is especially complicated in cases 
involving multiple languages”. As a result, the report recommends considering 
“greater standardization of locking and unlocking functions or more precise 
definitions of appropriate use of the lock status”.

4.5.4            In a document titled ‘Review of Issues for Transfers Working 
Group <http://forum.icann.org/lists/transfers-wg/docHMrHaPLWRt.doc> ’ (19 
January 2006), a working document developed by the Transfers Working Group, it 
is noted that “there seems to be ambiguity about what can be considered as 
registrar lock”. Potential next steps mentioned include a clarification by 
defining registrar lock within the policy. In addition, the document notes that 
“best practices regarding registrar lock need to be drawn out from current 
practices. Standards may need to be set regarding when use of lock is 
appropriate and not appropriate”.

====================

>From public comment received from Patrick Mevzek (see 
>http://forum.icann.org/lists/irtp-b/msg00003.html)

4) "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) 
(Issue #5); "

I would first would like that any discussion be put in line with the current 
protocols as "Registrar-Lock" was used with RRP which is now superseded by EPP 
for all gTLDs, and in EPP there are more that one status available to the 
registrar, where changes are more
fine-grained such as : clientXProhibited where X can be Transfer, Update, 
Renew, or Delete.

So I take from now on that we are here indeed speaking about the 
clientTransferProhibited status value that at registrar may use to
deny any outgoing transfer on a domain name he sponsors.

I believe that registrars should be free to use these statuses in any way they 
wish, or not all. This is specially true since registries are
starting to market services around their own set of available status, such as 
Verisign proposal at 
http://www.icann.org/registries/rsep/verisign-reglock-request-25jun09.pdf

So these statuses should be available to registrars, that can use them related 
to their own business procedures, rules and customers
services.

Instead of trying to limit registrars use of this status, I think it would be 
better to make sure that registrant and end customers have
the possibility to change this status online through their respective 
registrars. For that, besides handling spontaneous incoming
complaints from users, ICANN should commission yearly review of registrars 
using people acting as clients, unknown to the registrar
tested, and then they would be able to verify that each registrar let its 
registrant change that status value per their wishes.

I would also like to point out that in EPP, each status value can be associated 
with a message (in any language, as a language tag can be
provided alongside the message), explaining the reason of the status. This 
message is optional and seems to be seldom used, but it could be
useful for registrars to provide it as it would give an explanation for the 
basis that enabled this status value.

This would enable the registry and/or ICANN to immediately assess if the 
statuses are used for valid purposes and in accordance with
relevant policies, if registrars are required to file the message with a valid 
reason.

5) 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). "

As explained in my previous point:
- Registrar should be required to document why a domain is in 
clientTransferProhibited status (which would then automatically explain, 
without any explicit action, why a transfer request would fail)
- yearly verification should be made to ensure that indeed end clients are able 
to switch this lock on or off as they wish.
ICANN may maintain a webpage explaining, for each registrar, the specific 
procedure to follow for end users wanting to change the
locking attribute.

I also agree that this issue (number 5) should be handled together with the 
previous one (issue 4). And the example given as footnote on page 24 seems 
reasonable to me in order to assess how much having access to the locking 
procedure is easy at each registrar.