I would love to see a log of every transfer that was blocked and how many of those where because the registrant was being hijacked.

It's tough to tell. The cost of recovering of hi-jacked name can be stellar, and I have seen plenty of situations, such as client.com (stolen from NSI using a forged fax from a "Billy Bob Thornton") where the victim simply does not have the means or ability to pursue legal action. The "log of blocked transfers" is not going to provide meaningful information on the costs resulting from a hi-jacking (and that includes the lost time that we all devote to trying to get these things resolved informally). The transfers policy has been very effective at eliminating certain practices, of which we need not recite the history, that were clearly directed at shaking down registrants for renewals while denying transfers. The policy does allow room for registrants to consent to a variety of practices which are motivated by security. I, for one, would like to see a registrar that offers an option of "under no circumstances is this domain name to be transferred to another registrar" for high value names. Registrants *should* be able to select such a service, as long as it is voluntary and with notice. Of several hi-jackings I have seen lately, there has been a pattern of altered whois just prior to renewal. From this, I gather that some hi-jackers are targeting names near expiration on the assumption that this strategy will result in a higher yield of names that nobody will complain about. Figure, some names expire simply because the registrant has abandoned them. Hence, by targeting names near the end of expiration for hi-jacking, that class of registrants who intended to abandon the names are not going to be making complaints. It is probable that many such registrants just assume the name expired, so you aren't going to know "how many" were hi-jacked, since the registrants never complained. Another scenario I have seen a couple of times lately, is one in which the hi-jacker engages in multiple registrar transfers, while keeping the name servers the same, for periods of a year or longer. By the time the registrant notices, if the registrant notices, the underlying activity, and any logs of it, are long past. From the registrant's point of view, as long as the domain name is working, there is no apparent problem.

From yesterday's Wall Street Journal...

http://online.wsj.com/article/SB119068079815138145.html?mod=googlenews_wsj Web-Address Theft Is Everyday Event By KEVIN J. DELANEY September 25, 2007; Page B3 [...] "It's a complete rampage in our industry," says Monte Cahn, founder and chief executive of Moniker Online Services LLC in Pompano Beach, Fla., which handles domain services such as registrations and auctions. Bob Parsons, chief executive officer of GoDaddy.com Inc., says the domain registrar is aware of daily hijacking incidents, with the frequency having increased as Internet use grows. [...] In Mr. Inowlocki's case, his registrar says it hasn't had any luck recovering the domain from the registrar that yyy.com was transferred to -- Key-Systems GmbH in Germany. Key-Systems CEO Alexander Siffrin says that is because Mr. Inowlocki's registrar, TierraNet Inc. unit DomainDiscover, hasn't yet made a formal complaint or gotten a court order.

are you saying here that in your view the two behaviors referenced in the ICANN advisory, namely i) denying transfers in the grace period and ii) denying transfers for any change in whois information, are allowed for in the current policy? or are you saying they should be?

To be clear, I am not purporting to interpret the various relevant contracts for another party. The policy is open to interpretation in both instances. (i) Transfer during auto-renew: Looking at the denial prohibition post-expiration, I have already discussed the inherent problems with the wording here: * Nonpayment for a pending or future registration period However, the policy further clarifies: "Hence, in the event of a dispute over payment, the Registrar of Record must not employ transfer processes as a mechanism to secure payment for services from a Registered Name Holder. Exceptions to this requirement are as follows: (i) In the case of non-payment for previous registration period(s) if the transfer is requested after the expiration date, or (ii) In the case of non-payment of the current registration period, if transfer is requested before the expiration date." Both of these can be read to say that a Registrar may deny a transfer during the auto-renew grace period if that transfer is requested after the expiration date. But the larger issue here is the continual dodging of who is the "Registered Name Holder" after expiration of a domain name. (ii) Transfer within 60 days of registrant change This part is absolutely less ambiguous: "8 A domain name is in the first 60 days of an initial registration period. 9 A domain name is within 60 days (or a lesser period to be determined) after being transferred (apart from being transferred back to the original Registrar in cases where both Registrars so agree and/or where a decision in the dispute resolution process so directs)." Let's look at 8. What is "an initial registration period"? If you registered a domain name 6 months ago, sold me the domain name last week, when did my "initial registration period" begin? You are interpreting 8 to refer to the registry creation date for the domain name, but you are not explaining why that is the only way to read paragraph 8. One way to tell what things say is to consider what they DON'T say. Paragraph 8 refers to "an" initial registration period, which implies that a domain name may have more than one "initial registration period", because it sure as heck doesn't say "THE" initial registration period. Then we have paragraph 9. It states that a registrar transfer may be denied within sixty days "after being transferred". It does not say "after being transferred from another registrar". It is unconditional as to what sort of "transferred" is being referenced, and it parenthetically refers to an exception to the exception involving a particular registrar transfer scenario. Now, Elliot, I am absolutely certain that the things I have mentioned are capable of other interpretations, and I will admit to writing this in a rush. What I would suggest to you that the issue here is not which interpretation is "correct". I am also not suggesting that any possible interpretation is in any sense more reasonable than any other interpretation. The ONLY mechanism for determining the "correct" interpretation of ambiguous contract terms is through litigating them. But it is important not to confuse an interpretation of a policy with some notion of what the policy IS - particularly where you have policies that conflict with each other in interesting ways. I do not believe that you would agree that ICANN is the last word on contract interpretation. Now, concerning being strip-searched whilst shopping, as flattered as I may be that a discussion between us conjures up this image in your mind, I would point out that when one walks into a retail establishment, a number of policies are generally posted in a conspicuous place, and relate to things like bag inspection. Where one has consented to a policy that is not unreasonable, parties should be free to contract for services.

john, with respect, this is nonsense.

Well, I'm glad it was with respect. I'd be curious to know what it was without respect, but I believe it would involve a lot of arm waving and rich baritone vocalizations in either event.

when the rules were created the MEANINGS were clear.

I promise you that in every contract dispute, both sides are extremely clear on what the contract means. As I mentioned, reasonable minds can differ, and frequently do, in good faith.

the FAQ on the ICANN site references this specifically!

And the RAA states, specifically: "6. Entire Agreement. Except for any written transition agreement that may be executed concurrently herewith by both parties, this Agreement constitutes the entire agreement of the parties hereto pertaining to the subject matter hereof and supersedes all prior agreements, understandings, negotiations and discussions, whether oral or written, of the parties." Once a negotiation is concluded, then lawyers put these "integration clauses" into contracts to make it clear that subjective "meaning" external to the words of the document itself does not control. There is also a transfer dispute policy to address these issues. If it is not effective, then perhaps it should be re-visited.

the meaning was clear when the policy was enacted and we had clear abuse of the policy, followed by a long period of non-enforcement and NOW an ex poste facto legalistic rationalization.

There were specific egregious problems which have been effectively addressed by the policy. However, taking the RAA and the transfer policy as a whole, there are ambiguities which...

it is also just flat wrong to say the only way to interpret is to litigate. as I imagine you know, the most common method of resolving statutory ambiguity is to issue interpretations. the next most common is to pass regulations. ICANN is not a legislature. issuing interpretations is not only completely appropriate, to take any other path ("let's leave it to the courts to interpret") would be both wrong in spirit and have the effect of slowing any kind of effective policy-making to a halt. issuing interpretations should be done on a more regular basis AND only when there is fair ambiguity causing confusion in the drafting.

...depend upon how one views ICANN's role relative to these policies. The registrars and ICANN are contracting parties. I'm not suggesting that anyone litigate, but it is generally not the case where one party to a contract is given the controlling view of how that contract is to be interpreted. Most contract disputes never get anywhere near a court, because the parties work out ambiguities by methods other than an assertion of "I'm right and you're wrong". If the contract needs clarification, then by all means it should be clarified. The RAA requires that registrars contract for domain registrations for fixed annual terms. As Tim notes, whether the registry sets a "registry expiration date" ahead during auto-renew is not the same thing as the expiration date of the contract entered into by the registrar. So, where one comes out on post-expiration transfers depends on how one is reading "expiration". Now, GoDaddy is not a "rogue registrar" by any means, and I believe they have a good faith interpretation of these agreements that differs from ICANN's. To recognize a good faith difference of opinion is not to take sides, but I don't believe "ICANN's interpretation is controlling" is the correct approach to sorting it out, either. But looking at a "domain registration" as a set of obligations on a registrar, there are several time scales: 1. Obtain and record registrant data and transaction information. This is a three-year obligation. 2. Transmit nameserver data - upon registration. 3. Provide WHOIS data. Without looking, I believe this has to be done within 24 hours of 2. 3. Start to allow transfers. This obligation arises 60 days after "an initial registration". And so on. On "expiration", and for the purpose of observation and not comment, the Tucows agreement states: "In the event that you fail to renew your domain name in a timely fashion, your registration will expire and we may, at our discretion, elect to assume the registration and may hold it for our own account, delete it or we may sell it to a third party. You acknowledge and agree that your right and interest in a domain name ceases upon its expiration and that any expired domain name may be made available for registration by a third party." Now, I understand that a registration agreement defines the maximal power of the registrar, and any registrar may at any time, or even regularly, waive strict application of their own agreement. However, the Tucows agreement, like most agreements, states directly that the registrant's interest in the domain name terminates "upon its expiration" - in accordance with the RAA obligation to contract for registration services for fixed terms. Quite a few registrars make some sort of change to the whois data upon expiration (and by that I mean expiration of the registrant's contract with the registrar). In that instance, *who* is the Registered Name Holder. If I am reading Tucows agreement fairly, and assuming it is exercised as written, then at expiration if Tucows sells the domain name to a third party or assumes the registration for itself, then Tucows is the Registered Name Holder, and can be that *during* the registry auto-renew grace period. In that instance, the former registrant is no longer the Registered Name Holder, is not authorized to transfer the domain name, and the transfer should fail. In practice, Tucows might do any number of things, and I'm not particularly curious to know exactly what, but a close reading indicates that Tucows expressly disclaims any obligation to the registrant after "expiration". Now, there are utterly no conditions on when a registrar can unilaterally revoke a domain registration. Some registrars have an abuse policy relating to use of a domain name for spam or illegal purposes, some do not. Reading on... "We, in our sole discretion, reserve the right to deny, cancel, suspend, transfer or modify any domain name registration to correct a mistake, protect the integrity and stability of the company and any applicable registry, to comply with any applicable laws, government rules, or requirements, requests of law enforcement, in compliance with any dispute resolution process, or to avoid any liability, civil or criminal. You agree that we shall not be liable to you for loss or damages that may result from our refusal to register or cancel, suspend, transfer or modify your domain name registration." I don't see a "request of law enforcement" as an exception to the transfer policy. If Barney Fife calls you up from the Mayberry Sheriff's Office and asks you not to transfer a domain name, it appears that Tucows has assumed the discretion to comply with that request.

john, one of the things (among many) that I love about you is that you do not believe in litigation for litigation sake. I am surprised to hear you say what you did below.

Litigation is almost always a symptom of a failure of reason. The only point was that in a contract situation it is not normally the case that one party of the contract is assigned the role of issuing authoritative "interpretations" of the contract. If the parties cannot come to the same interpretation, then one has to find a neutral party to provide one. As we move toward a more rational RAA situation in which there are remedies other than "pull the plug", the issue of "who gets to define a violation" is going to be much more critical.

"For instance, around expiries, we were very simply giving Louis instructions that Registrars can't deny a domain transfer for a name that has expired" But isn't that the point? How can you bar a Registrar from denying a transfer of a domain that the Registrant no longer has rights to? If the Registrant is voluntarily agreeing (in the Domain Registration Agreement) that they are no longer the Registrant upon expiration, then the Registrar simply needs only to replace the original Registrant with their own name when the domain expires. At that point, any transfer request after the expiration date is an unauthorized transfer. Richard Lau -----Original Message----- From: owner-registrars@gnso.icann.org [mailto:owner-registrars@gnso.icann.org] On Behalf Of Ross Rader Sent: 28 September, 2007 10:42 PM To: john@johnberryhill.com Cc: 'elliot noss'; 'Registrars Constituency' Subject: Re: [registrars] FYI re: Transfers John Berryhill wrote:

...

when the rules were created the MEANINGS were clear.

I promise you that in every contract dispute, both sides are extremely clear on what the contract means. As I mentioned, reasonable minds can differ, and frequently do, in good faith.

Problem is, in this instance, the policy as written, was never intended to become the policy as applied. When the task force was documenting the policy, we were told time and time again not to sweat the legal stuff because it was always the plan to have the ICANN legal staff tighten up the wording during the implementation phase. Louis left right around this time and I suspect that this detail kind of just got dropped on the floor during the transition. I didn't really think twice about it, after all, I was generally happy with the language that was in there and not being a lawyer, wasn't informed enough to be concerned about the vagueness that you correctly point out. Anyways the salient point is - the intent of the policy is extremely clear and is quite well captured by the document. There were some areas that were overlooked, but these can be changed through the PDP. While there might be more than one way to interpret the transfer policy, there was only one intent of the GNSO. Its not like this is the U.S. Constitution and we have to guess at the state of mind of the drafters was. I'm still around, as are the others, you can simply ask. For instance, around expiries, we were very simply giving Louis instructions that Registrars can't deny a domain transfer for a name that has expired, unless the registrant didn't pay for the just-previous registration period for some reason (which is mostly a boundary case - registrations don't make it through an entire year or more without a bill being paid by someone at some point). This is the policy. It is very clear in my mind. What isn't clear were the words that were used to express the policy. Per the original agreement we had with staff, I think its perfectly reasonable for them to clean up the vagueness outside of a PDP or community consultation provided that the changes are consistent with the original policy intent. At the very least, this would be more productive than paying lawyers to talk circles around one another. -- Regards, Ross Rader Director, Retail Services Tucows Inc. http://www.domaindirect.com t. 416.538.5492

The original intent should certainly be documented and considered to see how much of it is still relevant. But the starting point for any proposed changes must be what has been published and relied upon by the entire industry. The internet today is different than it was a few years ago. While I do not doubt the original intent can be accurately captured, I have no idea how much of it is still relevant. Nor do I know the costs required to comply with a policy rewritten to better reflect "original intent". Business decisions, by necessity, must be based on what has been published by ICANN as official policy. I'm sure there are registrars who were involved in the original process, who developed their software based on intent rather than the published policy. However, many registrars were not involved in the original process. They relied on the written concensus policy posted by ICANN. Software has been written and business processes developed based on what was published. To change the current concensus policy without community consultation would therefore be inappropriate. Regards, Tom Barrett EnCirca, Inc -----Original Message----- From: owner-registrars@gnso.icann.org [mailto:owner-registrars@gnso.icann.org] On Behalf Of Ross Rader Sent: Friday, September 28, 2007 5:42 PM To: john@johnberryhill.com Cc: 'elliot noss'; 'Registrars Constituency' Subject: Re: [registrars] FYI re: Transfers John Berryhill wrote:

...

when the rules were created the MEANINGS were clear.

I promise you that in every contract dispute, both sides are extremely clear on what the contract means. As I mentioned, reasonable minds can differ, and frequently do, in good faith.

Problem is, in this instance, the policy as written, was never intended to become the policy as applied. When the task force was documenting the policy, we were told time and time again not to sweat the legal stuff because it was always the plan to have the ICANN legal staff tighten up the wording during the implementation phase. Louis left right around this time and I suspect that this detail kind of just got dropped on the floor during the transition. I didn't really think twice about it, after all, I was generally happy with the language that was in there and not being a lawyer, wasn't informed enough to be concerned about the vagueness that you correctly point out. Anyways the salient point is - the intent of the policy is extremely clear and is quite well captured by the document. There were some areas that were overlooked, but these can be changed through the PDP. While there might be more than one way to interpret the transfer policy, there was only one intent of the GNSO. Its not like this is the U.S. Constitution and we have to guess at the state of mind of the drafters was. I'm still around, as are the others, you can simply ask. For instance, around expiries, we were very simply giving Louis instructions that Registrars can't deny a domain transfer for a name that has expired, unless the registrant didn't pay for the just-previous registration period for some reason (which is mostly a boundary case - registrations don't make it through an entire year or more without a bill being paid by someone at some point). This is the policy. It is very clear in my mind. What isn't clear were the words that were used to express the policy. Per the original agreement we had with staff, I think its perfectly reasonable for them to clean up the vagueness outside of a PDP or community consultation provided that the changes are consistent with the original policy intent. At the very least, this would be more productive than paying lawyers to talk circles around one another. -- Regards, Ross Rader Director, Retail Services Tucows Inc. http://www.domaindirect.com t. 416.538.5492

You guys may be interested in this: http://blog.domaintools.com/2007/09/domain-renewal-accounting-loophole-expos ed-in-verisign-registry/

Richard Lau wrote:

Ross Rader wrote: "Inappropriate is ripping off registrants to line your own pocket."

Isn't the "internal transfer fulfilment" (or whatever one wants to call it) just that? The ICANN policy (as JB just pointed out) was quite clear in its intention that if a domain isn't renewed by a registrant, then the domain is to be deleted.

Not unless the Registrant intended to keep the name. In which case, they should be allowed to do so. Net of this, its not unreasonable for a change of registrant to take place if the prior registrant had originally intended simply not to renew. ICANN's policy is simply indicating that if the renewal doesn't happen, the domain should be deleted. In this case, the renewal does take place pursuant to a change of registrant.

The RGP period has also been contracted around. Many registrars have their registrants agree that the domain can be transferred immediately upon expiration with no "emulated" RGP (while others actually offer a longer fake RGP of more than 30 days).

RGP isn't a policy, its a registry service. Registrars are under no obligation to extend the registries RGP to their clients. Many registrars have instead implemented their own and as you point out, some have done nothing. I don't think its reasonable at any level for a post-expiry change of registrant to take place unless the original registrant has some means by which to reverse the process and reclaim their registration. Mistakes happen, names expire by accident. Registrants shouldn't be unduly penalized when this happens. -- Regards, Ross Rader Director, Retail Services Tucows Inc. http://www.domaindirect.com t. 416.538.5492

From the Wall Street Journal...

http://online.wsj.com/article/SB119068079815138145.html?mod=googlenews_wsj [...] "In Mr. Inowlocki's case, his registrar says it hasn't had any luck recovering the domain from the registrar that yyy.com was transferred to -- Key-Systems GmbH in Germany. Key-Systems CEO Alexander Siffrin says that is because Mr. Inowlocki's registrar, TierraNet Inc. unit DomainDiscover, hasn't yet made a formal complaint or gotten a court order." Any recommendations here? Yyy.com had a fraudulent change occur on the Admin Contact email while yyy.com was at DomainDiscover. Domain immediately transferred out to Key-Systems. Since the Auth followed all the standard procedures, the TDRP is not a valid form of complaint. Most registrars seem to have adopted a policy that in this case would have seen the return of yyy.com to DomainDiscover, but only after DomainDiscover issued a Letter of Indemnification to Key. However, in this case, it appears Key is stating that they will not reverse the transfer unless a court order or UDRP ruling is presented. Any thoughts/suggestions? Thx Richard Lau =========================== Cache Date: 2007-07-16 Registrar: DOMAINDISCOVER Administrative Contact, Technical Contact, Zone Contact: because address New York, NY 10016 US 987-654-3210 ri_domains@yahoo.com Then by July 21, 2007, while still on DomainDiscover, it changed to: Cache Date: 2007-07-21 Registrar: DOMAINDISCOVER Administrative Contact, Technical Contact, Zone Contact: YYY World Ltd Hans Odegard PO Box 659, Posthusstraeti 7 Reykjavik, 121 IS (281)912-1120 (281)912-1120 [fax] yyy@lawyer.com And immediately transferred out to Key-Systems GMBH Cache Date: 2007-07-23 Registrar: KEY-SYSTEMS GMBH owner-contact: P-HYO74 owner-organization: YYY World Trading Ltd owner-fname: Hans owner-lname: Odegard owner-street: PO Box 659, Posthusstraeti 7 owner-city: Reykjavik owner-zip: 121 owner-country: IS owner-phone: 12819121120 owner-fax: 12819121120 owner-email: yyy@lawyer.com