Difference between revisions of "Inter-Registrar Transfer Policy"
m (added Category:DNS Policy using HotCat) |
|||
| Line 6: | Line 6: | ||
In November, 2008, certain changes were made to the policy following advice from the [[ICANN Board]].<ref>[http://www.namesmash.com/icann-at-work-on-inter-registrar-transfer-policy/ NameSmash]</ref><ref>[http://192.0.43.22/en/announcements/announcement-17mar08.htm ICANN Announcements]</ref> | In November, 2008, certain changes were made to the policy following advice from the [[ICANN Board]].<ref>[http://www.namesmash.com/icann-at-work-on-inter-registrar-transfer-policy/ NameSmash]</ref><ref>[http://192.0.43.22/en/announcements/announcement-17mar08.htm ICANN Announcements]</ref> | ||
| − | + | In 2011, the [[GNSO]] again reviewed the policy with respect to the issues of domain hijacking, the urgent return of an inappropriately transferred name and "lock status." On May 31st, 2011, the IRTP Working Group submitted a report featuring 9 suggested changes to the policy.<ref>[http://www.domainpulse.com/2011/05/31/icann-nine-recommendations-to-improve-the-inter-registrar-transfer-policy-irtp-part-b-wg-submits-final-report/ DomainPulse]</ref> The revised policy was open for comments from July 8th, 2011, to August 8th, 2011.<ref>[http://www.icann.org/en/announcements/announcement-2-08jul11-en.htm ICANN Announcements]</ref> | |
===Initial Issues=== | ===Initial Issues=== | ||
| − | While the policy was under development ICANN raised few issues and requested for the public to give their comments so that an effective policy could be made. The questions published by ICANN were:<ref>[http://www.namesmash.com/icann-at-work-on-inter-registrar-transfer-policy/ NameSmash Blog]</ref> | + | While the policy was under development, ICANN raised few issues and requested for the public to give their comments so that an effective policy could be made. The questions published by ICANN were:<ref>[http://www.namesmash.com/icann-at-work-on-inter-registrar-transfer-policy/ NameSmash Blog]</ref> |
* Should registrars keep the email address of registrant in their database, so that he can be easily contacted when needed? | * Should registrars keep the email address of registrant in their database, so that he can be easily contacted when needed? | ||
* Should the security of registrant data be increased in order to prevent hacking and spoofing? Should there be a Form of Authorization present to apply a double check? | * Should the security of registrant data be increased in order to prevent hacking and spoofing? Should there be a Form of Authorization present to apply a double check? | ||
| Line 15: | Line 15: | ||
===2012 Changes=== | ===2012 Changes=== | ||
| − | In January, 2012, ahead of its February [[ICANN 43]] meeting, the organization announced that it was considering changes to its IRTP. The GNSO council approved those changes, which | + | In January, 2012, ahead of its February [[ICANN 43]] meeting, the organization announced that it was considering changes to its IRTP. The GNSO council approved those changes, which defined a universal 5 day maximum allowable lock period for domains that have had changes made to the registrant's name in the [[Whois]] record. The new rule was seen as largely a response to [[GoDaddy]]'s 60 day lock policy, which had been a continued target for criticism. GoDaddy, through its representative [[James Bladel]], was involved in creating the proposed changes.<ref>[http://domainincite.com/end-in-sight-for-go-daddys-60-day-transfer-lock/ End in Sight for Go Daddys 60 Day Transfer Lock, DomainIncite.com]</ref> |
| + | |||
| + | ==GNSO [[Policy Development Process to Review the Transfer Policy]], 2021== | ||
| + | In February 2021, the GNSO initiated a [[Policy Development Process]] to review ICANN's transfer policies. Spurred in part by policy considerations associated with ICANN's [[Temporary Specification for gTLD Registration Data|Temporary Specification]] and [[Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP)|Expedited Policy Development Process]] in response to the EU [[General Data Protection Regulation|GDPR]], the [[Policy Development Process to Review the Transfer Policy|review]] is directed at eight issue areas. | ||
==Additional Links== | ==Additional Links== | ||
Latest revision as of 22:47, 12 May 2021
The Inter-Registrar Transfer Policy (IRTP) was developed by ICANN for the safe, straight-forward transfer of domain names from one registrar to another.[1] The policy contains information about the method of transferring a domain name, dispute resolution mechanism and the method of undoing the transfer if it was done as a result of an error.[2]
Development
The IRTP was developed through a consensus building process. In early 2003, the Transfer Task Force presented a report to the GNSO council. The report had 29 policy recommendations, which were accepted by the GNSO and were adopted by ICANN. ICANN coordinated with the Transfer Assistance Group (TAG) and GNSO to implement the transfer procedure. This policy has been required to be followed by all ICANN-accredited registrars throughout the world since November 12th, 2004.[3] The background documents and GNSO reviews on IRTP can be downloaded from here.
In November, 2008, certain changes were made to the policy following advice from the ICANN Board.[4][5]
In 2011, the GNSO again reviewed the policy with respect to the issues of domain hijacking, the urgent return of an inappropriately transferred name and "lock status." On May 31st, 2011, the IRTP Working Group submitted a report featuring 9 suggested changes to the policy.[6] The revised policy was open for comments from July 8th, 2011, to August 8th, 2011.[7]
Initial Issues
While the policy was under development, ICANN raised few issues and requested for the public to give their comments so that an effective policy could be made. The questions published by ICANN were:[8]
- Should registrars keep the email address of registrant in their database, so that he can be easily contacted when needed?
- Should the security of registrant data be increased in order to prevent hacking and spoofing? Should there be a Form of Authorization present to apply a double check?
- Should there be a provision for handling partial bulk transfers? Partial bulk transfers are those in which a registrar transfers some of its domains and not every domain.
2012 Changes
In January, 2012, ahead of its February ICANN 43 meeting, the organization announced that it was considering changes to its IRTP. The GNSO council approved those changes, which defined a universal 5 day maximum allowable lock period for domains that have had changes made to the registrant's name in the Whois record. The new rule was seen as largely a response to GoDaddy's 60 day lock policy, which had been a continued target for criticism. GoDaddy, through its representative James Bladel, was involved in creating the proposed changes.[9]
GNSO Policy Development Process to Review the Transfer Policy, 2021
In February 2021, the GNSO initiated a Policy Development Process to review ICANN's transfer policies. Spurred in part by policy considerations associated with ICANN's Temporary Specification and Expedited Policy Development Process in response to the EU GDPR, the review is directed at eight issue areas.