FYI re: Transfers
Staff has posted a notice of advisory regarding the domain transfers policy. This was not posted pursuant to the work of the Transfers WG or the GNSO Council - it is an independent effort. I have yet to read and understand it, but I would be interested in your respective feedback on the document. http://www.icann.org/announcements/announcement-19sep07.htm -- Regards, Ross Rader Director, Retail Services Tucows Inc. http://www.domaindirect.com t. 416.538.5492
I think this is a constructive notice from ICANN. Registrars are certainly inconsistent whether out-going transfers are allowed once a domain has expired. We have seen several instances of registrars denying transfers that are in the auto-renewal period. One reason stated is that the registrar has already invoiced the customer for the renewal and thus is "owed" payment. Another stated reason is the belief that expired domains are not eligible for transfer. I think the notice should include a simple statement: "domains that have expired and are in the auto-renewal period are still eligible for transfer to another registrar except under nine limited circumstances...." Tom Barrett EnCirca -----Original Message----- From: owner-registrars@gnso.icann.org [mailto:owner-registrars@gnso.icann.org] On Behalf Of Ross Rader Sent: Thursday, September 20, 2007 9:30 AM To: Registrars Constituency Subject: [registrars] FYI re: Transfers Staff has posted a notice of advisory regarding the domain transfers policy. This was not posted pursuant to the work of the Transfers WG or the GNSO Council - it is an independent effort. I have yet to read and understand it, but I would be interested in your respective feedback on the document. http://www.icann.org/announcements/announcement-19sep07.htm -- Regards, Ross Rader Director, Retail Services Tucows Inc. http://www.domaindirect.com t. 416.538.5492
Hello, many registrars claim that the agreement between registrant and registrar ends on the day of expiration. In fact, a good part of the adword market relies on this. Under this assumption there is no autorenewal grace period for the registrant. To address this issue there would have to be a requirement that the registrant is still allowed to access his domain during AGP. This raises a whole bunch of other questions like what is happening with associated nameservers that the current registrar provides. I have the impression that it will be very difficult to find solution here. Marcus
I think this is a constructive notice from ICANN.
Registrars are certainly inconsistent whether out-going transfers are allowed once a domain has expired.
We have seen several instances of registrars denying transfers that are in the auto-renewal period. One reason stated is that the registrar has already invoiced the customer for the renewal and thus is "owed" payment. Another stated reason is the belief that expired domains are not eligible for transfer.
I think the notice should include a simple statement:
"domains that have expired and are in the auto-renewal period are still eligible for transfer to another registrar except under nine limited circumstances...."
Tom Barrett EnCirca
-----Original Message----- From: owner-registrars@gnso.icann.org [mailto:owner-registrars@gnso.icann.org] On Behalf Of Ross Rader Sent: Thursday, September 20, 2007 9:30 AM To: Registrars Constituency Subject: [registrars] FYI re: Transfers
Staff has posted a notice of advisory regarding the domain transfers policy. This was not posted pursuant to the work of the Transfers WG or the GNSO Council - it is an independent effort. I have yet to read and understand it, but I would be interested in your respective feedback on the document.
http://www.icann.org/announcements/announcement-19sep07.htm
-- Regards,
Ross Rader Director, Retail Services Tucows Inc.
http://www.domaindirect.com t. 416.538.5492
-- Global Village GmbH Tel +49 2855 9651 0 GF Marcus Faure Mehrumer Str. 16 Fax +49 2855 9651 110 Amtsgericht Duisburg HRB9987 D46562 Voerde eMail info@globvill.de Ust-Id DE180295363
"domains that have expired and are in the auto-renewal period are still eligible for transfer to another registrar except under nine limited circumstances...."
There is a fundamental problem here, though. If I enter into a service contract on 20 September 2007 with Tom, and the contract specifies that I am to receive the contracted service for one year, then Tom's obligation to me ends on 20 September 2008. Now, our contract may include a number of voluntary renewal provisions and may limit Tom's obligation to perform specific services for a longer period than one year, however when I enter into a contract for services for a term, then I am entitled to know when that term ends. Both parties are entitled to clarity as to term. This reduces to a Groucho Marx quiz question: 1. "How long does a one year contract last?" It doesn't require a lawyer to answer that question. But I would put the following question to the advocate of nebulous "extra-term obligations": 2. Specifically how long is a registrar obligated to provide services under a one year registration contract? A year plus 30 days? A year plus 45 days? If one cannot define the term of obligation, then I think more than one registrar is going to have its accountants and auditors slitting their wrists if they cannot assign a fixed term of obligation to a registration contract. Post contract-expiration terms can be permissive, but I cannot see how they can be made mandatory - at least not in the US since passage of the 13th Amendment. On the "whois change" matter, I believe Tim Ruiz may have a few words about voluntary and non-onerous security measures. I can say that in hi-jacking situations, if the name hits GoDaddy, then one has at least 60 days to catch up with it there. When a domain can be subject to two registrar transfers in rapid succession, then the Transfer Dispute policy breaks. The TDRS is premised on a one-hop unauthorized transfer. In a two-hop hi-jack, the second hop is formally "authorized", and the first hop cannot be remedied because the intermediate registrar cannot transfer the domain name back even if the first hop WAS unauthorized.
Note that the notice says that comments may be posted at: http://forum.icann.org/lists/retransfers-comments/ However, I do not see any means of posting or instructions for posting comments at that URL. Daniel J. Wright wright@pair.com Lead Software Developer, pairNIC https://www.pairnic.com pair Networks, Inc. http://www.pair.com On Thu, 20 Sep 2007, Ross Rader wrote:
Staff has posted a notice of advisory regarding the domain transfers policy. This was not posted pursuant to the work of the Transfers WG or the GNSO Council - it is an independent effort. I have yet to read and understand it, but I would be interested in your respective feedback on the document.
http://www.icann.org/announcements/announcement-19sep07.htm
-- Regards,
Ross Rader Director, Retail Services Tucows Inc.
http://www.domaindirect.com t. 416.538.5492
Here is the text of the proposed advisory for those interested: PROPOSED Advisory Registrar Advisory Concerning the Inter-Registrar Transfer Policy The purpose of this advisory is to assist ICANN-accredited registrars in understanding that under the Inter-Registrar Transfer Policy: 1. Registrars are prohibited from denying a domain name transfer request based on non-payment of fees for pending or future registration periods during the Auto-Renew Grace Period; and 2. A registrant change to Whois information is not a valid basis for denying a transfer request. The Inter-Registrar Transfer Policy ("Transfer Policy") was adopted by ICANN as a consensus policy in 2004 in order to assist domain name holders in transferring their domain names from one ICANN-accredited registrar to another upon request. The Transfer Policy is available at http://www.icann.org/transfers/policy-12jul04.htm. 1. Pursuant to the Transfer Policy, registrars are prohibited from denying domain name transfer requests based on non-payment of fees for pending or future registration periods during the Auto-Renew Grace Period. This section of the advisory considers the scenario when a registrar denies a transfer request made by the registrant during the registration period after expiration, if the registrant has not paid for renewal. Pursuant to Section A.3 of the Transfer Policy, registrars are permitted to deny outgoing transfers of gTLD domain names only in the limited circumstances specifically enumerated by the Transfer Policy. One of these circumstances is: 5. No payment for previous registration period (including credit card charge-backs) if the domain name is past its expiration date or for previous or current registration periods if the domain name has not yet expired. In all such cases, however, the domain name must be put into "Registrar Hold" status by the Registrar of Record prior to the denial of transfer. The Transfer Policy further states that, "Instances when the requested change in Registrar may not be denied include, but are not limited to: Nonpayment for a pending or future registration period..." In those cases where a registrant has paid all past registration fees, but has not paid for renewal, and the domain name is in the registration period after expiration, registrars are prohibited from denying a transfer request, as the registration period after expiration is either a "pending or future" registration, during which time the Transfer Policy prohibits denial of transfers on the basis of non-payment. While issues related to domain name transfers initiated during the Auto Renew Grace period are under consideration by the GNSO's Transfers Working Group, ICANN's intention with this advisory is to provide clarification of existing policy. Registrars are advised that under the Transfer Policy they may not deny a transfer request on the basis of non-payment of fees for the registration period after the expiration date, unless the denial is based on non-payment for a past registration period. Registrars that impose policies or procedures on their registrants that are contrary to this determination are in violation of the Transfer Policy. 2. A registrant change to Whois information is not a valid reason to deny a transfer request. A registrant's objection to transfer is not valid unless it is obtained voluntarily. This section of the advisory considers the scenario when a registrar requires a registrant to provide consent to deny transfer requests for a certain period of time (usually 60 days) in order for the registrant to update its Whois data. Section A.3 of the Transfer Policy enumerates nine independent bases that a registrar may rely on to deny a domain name transfer request. Registrant updates to Whois contact details is not enumerated as a valid basis to deny a transfer request in the Transfer Policy. In addition, ordinary changes to Whois data fields are not evidence of fraud and therefore not a basis to deny a domain name transfer request. Pursuant to Section A.3 of the Transfer Policy, registrars are permitted to deny transfer requests if they have obtained, "6. Express written objection to the transfer from the Transfer contact. (e.g. - email, fax, paper document or other processes by which the Transfer Contact has expressly and voluntarily objected through opt-in means)". While the language in parenthesis is provided as an example in paragraph enumerated 6 of Section A.3 of the Transfer Policy, this language is instructive regarding what types of express written objections were envisioned as acceptable as a basis to deny a transfer request - only those objections that are provided expressly and voluntarily. Subsection 3.7.7.1 of the Registrar Accreditation Agreement ("RAA") requires registrars to include language in their registration agreements that obligates registrants to maintain "accurate and reliable contact details and promptly correct and update them during the term of the...registration." By agreeing to such language, registrants are under a strict requirement to update their Whois contact details when they change. Subsection 3.7.7.2 of the RAA requires registrars to include language in their registration agreements that authorizes them to cancel domain name registrations for any willful breach of these obligations. Accordingly, failure by a registrant to timely update Whois contact details may result in the cancellation of a domain name. Registrars that have implemented processes that require registrants to consent to deny transfer requests in order to update Whois contact information are not obtaining voluntary express objections and therefore such objections cannot be used as a basis for denying a transfer pursuant to Section A.3 of the Transfer Policy. Registrars are advised that any express written objections to transfer obtained by registrars through compulsory means, including express written objections obtained before allowing registrants to make required Whois data changes, are involuntary and therefore not a valid basis to deny transfer requests. Conclusion To ensure compliance with Registrar Accreditation Agreement requirements, all ICANN-accredited registrars are encouraged to review their domain name registration transfer processes and relevant domain name registration documents to make certain they comply with the Inter-Registrar Transfer Policy. Specifically, registrars' processes and documents should be consistent with the interpretations set forth in this advisory regarding Section A.3 of the Transfer Policy pertaining to the Auto-Renew Grace Period and the type of consent required to deny transfers.
Here is the utterly incomprehensible phrase that jumps out twice in this document:
the domain name is in the registration period after expiration,
What is the "registration period after expiration"? The complete phrase isn't used, because the nonsense becomes clearer. If you ask yourself, "The registration period after expiration of what?" you realize that what the ICANN proposed advisory is saying here is: --the registration period after expiration of the registration period-- Oh, THAT registration period... Consider the sequence of events described in Weingrad v. Telepathy et al., which involved a domain name that the Registrant allowed to slide into the RGP, and then still demanded transfer of the domain name while refusing to pay the RGP fee. The story begins at page 4: http://wwww.johnberryhill.com/weingrad.pdf
2. A registrant change to Whois information is not a valid reason to deny a transfer request.
So, Registrars are to verify whois data UNLESS the Registrant providing fraudulent whois data is requesting transfer of the domain name. In that case, forget about verifying whois data, and let the hi-jacker, who obtained the account login information and changed the WHOIS yesterday, run with the name. We now have an exception to the general obligation to implement reasonable policies to obtain correct whois data. Is there a "Deadbeats and Hijackers Constituency" driving these "clarifications"?
Ooops make that www.johnberryhill.com/weingrad.pdf After all these domain disputes.... I can't type anything correctly.
Is there a "Deadbeats and Hijackers Constituency" driving these "clarifications"?
john, try the "average users who get screwed out of using the provider of their choice" constituency. membership is extremely large. comments inline. On 21-Sep-07, at 12:08 PM, John Berryhill wrote:
Here is the utterly incomprehensible phrase that jumps out twice in this document:
the domain name is in the registration period after expiration,
What is the "registration period after expiration"?
I will not excuse the tortured syntax but I suspect you are smart enough to know this refers to the registrar-defined period, not to exceed 45 days, after expiry and before RGP.
2. A registrant change to Whois information is not a valid reason to deny a transfer request.
So, Registrars are to verify whois data UNLESS the Registrant providing fraudulent whois data is requesting transfer of the domain name. In that case, forget about verifying whois data, and let the hi-jacker, who obtained the account login information and changed the WHOIS yesterday, run with the name.
again, I think you well know that the advisory is intended to deal with minor changes in the whois that are used to create an excuse to deny transfers. the typical situation that we encounter is the combination of these two "security-friendly" provisions: - renewal time approaches; - registrant, often a small business, wants to change suppliers and realizes that their whois info needs to be updated (they moved, employee has left/was fired, etc.) and makes the change and then initiates a transfer; - "security-friendly" policy 1 --------> sorry, you made a change and now you can't transfer the name for 60 days. of course this puts them past expiry leading to....... - "security-friendly" policy 2 --------> sorry you are past expiry, you can now only renew not transfer. a few things are important to note. first, what ICANN is reiterating is the current policy. now I am the last guy to say "a rule is a rule is a rule" but let's be clear that these ARE the current rules, are the result of consensus policy inside the ICANN process (one of the very very few things to actually make it through the process) and were put in place to facilitate registrants freedom to work with the supplier of their choice. second, numerous registrars simply flout the existing policy and ignore it. ICANN has done nothing. I, and others, have complained about this loudly and publicly. they should be commended (ICANN I commend you!) for issuing an advisory. now they need to follow that with enforcement. third, the security issues that are raised can be dealt with in a number of alternative ways, too numerous to enumerate here. fourth, the inability to transfer because of the policy violations happens orders of magnitude more often than hijacking attempts. last, the industry has done a FANTASTIC job of rectifying wrongdoing. when there is a hijacking of a name of any value registrars work together to rectify. in 2000 I created the indemnity system to allow us to cover NSI's often exposed ass. the network of compliance groups (bigger registrars) and operators (smaller registrars) does an amazing job of righting wrongs. there are simply more efficient and fair ways to do this than by denying transfers in violation of ICANN consensus policy. the issues raised as "security concerns" are always about fraud. no question these happen on an exceptional basis. trying to correct them by restricting transfers in violation of policy as above is like strip searching every customer leaving wal mart in an attempt to stop shoplifting! Regards Elliot Noss
participants (7)
-
Bruce Tonkin -
Dan Wright -
elliot noss -
John Berryhill -
Marcus Faure -
Ross Rader -
Thomas Barrett - EnCirca