[gnso-irtp-b-jun09] Lock status information
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.