Home / Blogs

Post Delegation Dispute: A Once Supportable Concept Proposed by the IRT is Now Unsupportable

This comment is being presented in my personal capacity and does not represent the views of my employer (Neustar, Inc.) and its subsidiaries or affiliates, or the Implementation Recommendations Team.

Ok. I admit it. I supported the concept of a post delegation dispute resolution process for generic Top-Level Domains (gTLD) Registries. I served as the only gTLD registry member of the Implementation Recommendation Team (IRT) appointed by the Intellectual Property Constituency of the Generic Names Supporting Organization of ICANN. I was one of the authors of the IRT Recommendation in favor of a Post Delegation Dispute Resolution Procedure. The IRT labored for many weeks on this proposal to ensure that any process that resulted both addressed the needs of the Intellectual Property community, and ensured that registries were protected against overzealous trademark owners seeking to blame domain name registries for the infringement that occurs within a TLD.

After much discussion and debate (as other members of the IRT can attest), and despite the risk of being ostracized by my gTLD registry peers, I honestly believe the IRT was successful in creating a process that would have been tolerable (not ideal, but tolerable) for the Intellectual Protection community, the gTLD Registry community as well as the general Internet community. The proposal was contained in the IRT Final Report released on May 29, 2009 (IRT Report). Not only did I help to author this proposal, but I volunteered to speak about (and in favor of) the proposal at the ICANN consultations in Sydney, New York and London in June and July of this year. I still support that proposal made by the IRT.

However, ICANN turned the proposal for a Post Delegation Dispute Resolution Process (PDDRP) upside down without providing any detailed explanation. Nor did ICANN consult with the group presenting the original PDDRP, but rather opted instead to release a new proposed PDDRP (Proposed PDDRP) which is devoid of many of the key elements that made the process tolerable. In fact, ICANN’s new PDDRP is so radically different from the one we originally proposed that I would like to state for the record that I cannot—and will not—support it.

By no means am I saying that the IRT proposal for a PDDRP was perfect. In fact, it was far from it. But that said, just five days after the release of the Affirmation of Commitments in which ICANN committed to “provide detailed explanations for decisions, including how comment have influenced the development of policy consideration” (See Paragraph # 7), ICANN has failed to explain why it stripped the IRT proposal for a PDDRP of many of the core concepts that made the process fair and balanced. Below is a discussion of some of those concepts.

I. ICANN Takes Itself Out of the Process

A. ICANN Removes itself from the front end

Footnote 43 of the IRT Report clearly states that:

The IRT is aware of concerns that have been raised in the past—some in the DAG public comment process—about ICANN’s compliance efforts. Nonetheless, the IRT believes that the obligation for addressing post-delegation disputes between ICANN and the contracted registry properly rests with ICANN. [Emphasis mine].

Yet, in one parenthetical statement in the Proposed PDDRP (and without any support found in the public comments), all of the work of the IRT on this issue was eliminated. In ICANN’s Proposed PDDRP, ICANN goes so far to dismiss the work of the IRT by stating:

“Although there has been some suggestion that prior to commencing such a procedure, that ICANN first be notified and asked to investigate, from a practical standpoint, it does not make sense to add this layer to the procedure. It would unnecessarily slow the process.”

“Some suggestion”? The inclusion of this phrase absolutely shocked me. The IRT spent almost half of the PDDRP section talking about ICANN’s role in both the initiation of a complaint as well as in deciding on the ultimate remedies and how important that role was. The concept was absolutely vital to the members of the IRT, me included; in fact, the entire rationale for much of the proposal was to assist ICANN doing its job in enforcing the Registry Agreement. Yet without explanation, ICANN dismisses the IRT Proposal by implying that requiring ICANN to actually do its job would unnecessarily slow the process down.

It is understandable that ICANN does not want this job as it certainly would require more work, diligence, resources and enforcement by members of the ICANN staff. However, having ICANN involved was deemed essential to me personally as well as to other members of the IRT because it provided a “check and balance” between (i) an IP owner that has truly been harmed by the systemic bad faith actions of an irresponsible registry operator and (ii) the overzealous trademark owner that sought remedies against the registry operator, when the appropriate party to go after is actually the owner of the infringing domain name registrations.

I believe the IRT was of the view that if the Registry were indeed engaging in the type of behavior addressed by the PDDRP, and such conduct was a violation of the Registry Agreement, that ICANN should enforce that agreement and apply the remedies it deemed appropriate (within the bounds of the Agreement). Why should an aggrieved third party have to spend money in an arbitration-type proceeding when ICANN could simply do its job and enforce the Registry Agreement? Why should ICANN’s compliance, with its ever-expanding headcount, not be required to investigate these matters and take appropriate swift action where necessary? If anything would “unnecessarily slow down the process,” wouldn’t third party arbitration be the thing that created the “unnecessary layer” as opposed to ICANN actually enforcing its agreement?

On the other hand, an ICANN investigation can also help a registry operator that has been victimized by an overzealous trademark attorney seeking to go after the registry simply because it has the deeper pockets or it is easier to reach than the ultimate registrants causing the infringements. By requiring ICANN to investigate, it could weed out the frivolous actions by serving as a deterrent. In other words, if ICANN finds no merit to a claim by an overzealous trademark attorney, it is quite possible that that trademark attorney may decide not go further and pursue the arbitration knowing there is a good probability that it will lose if it does so.

B. ICANN Removes Itself from the Back-end

Not only has ICANN removed its obligation to investigate potential breaches of the Registry Agreement, but it has taken itself out of the role of deciding what remedy is appropriate in cases where a panel does find that the Registry has breached its Registry Agreement by using its TLD to infringe the rights of IP owners (at the top-level) or engaging in a substantial pattern or practice of specific bad faith intent to profit from the same of trademark infringing domain names.

In the IRT proposal, although the panel could recommend sanctions to ICANN for the actions of a Registry, ultimately it was ICANN that could determine what the appropriate remedies were. This was placed into the IRT Report to provide a check and balance against the possibility of having a Panelist (who is not experienced in contract enforcement between registries and ICANN) order a punishment that may not “fit the crime.”

Although ICANN states that “all determinations by a panel will be immediately appealable to a court…,” how would that really be accomplished? If a panel decides that the registry engaged in this behavior and orders a termination of the registry agreement, how is that really appealable in a courtroom setting? (At the very least, if ICANN was to elect a remedy and enforce the requirements, the registry could challenge ICANN on a breach of contract ground.) If ICANN passes this off to the third party, then who does the Registry take to court—and on what grounds? In U.S. legal terms, what is the basis for either subject matter or personal jurisdiction?

II. ICANN Changes the Grounds for Dispute

The IRT Report recommended three separate grounds to serve as the basis for a post delegation dispute. Two of the three grounds, which were the only ones applicable to a dispute at the top-level, included situations in which a Registry acted inconsistently with representations made in the Registry Agreement.

ICANN staff without consultation or even any other supporting comments or documentation substituted its own judgment and revised these grounds eliminating any tie-in to the Registry Agreement with ICANN. Again, it appears like this was an attempt by ICANN to completely remove itself from the dispute process. After all, if the grounds for a dispute were based (even in part) on the Registry Agreement, then wouldn’t the ICANN community expect ICANN to actually enforce that agreement rather than rely solely on a third party to resolve the dispute? By removing the tie between the contract the Registry actually signs and the complaint of bad behavior, then ICANN can successfully argue (at least from a public relations perspective) that it is not ICANN’s job to do such enforcement.

The third ground looks very similar to the one proposed by the IRT, most likely because it was the only ground not based on the Registry Agreement and therefore there would be less of an expectation that ICANN’s compliance department would be involved.

III. ICANN has Eliminated all Protections for Abusive Filings

A. ICANN Removes Fees Barrier

In addition to the above, ICANN has also eliminated other deterrents for preventing abusive filings by overzealous trademark owners. In the IRT Report, we stated:

“The complainant shall participate in the DRP. To initiate a Post-Delegation Dispute, the complainant must pre-pay an additional fee to the DRP. The IRT further recommends that this fee be set to cover the provider’s cost as well as the Registry Operator’s cost should Registry Operator prevail. Furthermore, the IRT believes that the complainant should be required to prepay an additional amount that shall be paid to the Registry Operator if the complaint is found by the Panel to be “without merit” (“Penalty Fee”).” [Emphasis Added].

In addition, the IRT states that the “amount of the fee should be meaningful enough to deter arbitrary and capricious claims.” Furthermore, it provides a sample set of recommended fees in Appendix G, but notes: “The fee amounts used are for illustrative purposes only and merely reflect the IRT’s recommendation that the fees by substantial enough to cover costs and deter gaming of the system by either trademark owners or Registry Operators.”

Without any discussion in its proposal, ICANN has drastically eroded this barrier to filing a post-delegation dispute by: (1) leaving it to the sole discretion of the accredited dispute provider to set the fees based only on “cover[ing] the administrative fees; (2) stating that the fees are “intended to be reasonable”; and (3) not providing any guidance on the “penalty fees,” nor requiring them to be paid in advance by the complainant. Translated, this means that the fees will be relatively low and will enable any third party to file a complaint. Without a meaningful investment up front, there will be no deterrence against the overzealous trademark owner.

Furthermore, to add insult to injury, at any point in time that a complaint is filed, ICANN recommends that “each party shall be required to submit the full amount of the Provider administrative fees and the Panel fees at the outset of the proceedings.” Although the IRT recommended that the complainant prepay the fees, it in no way required the Registry to pre-pay any fees (although it would have to pay if it lost). This is far too large of a burden for the Registry to bear in order to defend itself. I note that in no other dispute proceeding (whether the UDRP or any court action) is it required that a defending party prepay fees. The threat of this alone by an overzealous trademark owner or by multiple trademark owners at once is enough to scare or coerce the legitimate Registry operators acting in good faith.

B. No Review on Default

Under the UDRP, even if the registrant does not file a response a response, the Panel is still required to do a full analysis of the complaint to see if what was alleged truly amounts to bad faith. In fact, under the proposed URS, the IRT took great pains to ensure that in a default situation, the administrative panel would still have to review the Complaint and scrutinize it to ensure that the complainant successfully meets a high burden of proof before issuing an order against the Registrant. ICANN even agreed with this sentiment in its proposed implementation of the URS by stating “All default cases, however, proceed to Examination.” (See Part I, Paragraph 6.3)

I find it amazing that from ICANN’s standpoint, what is good for the registrant of one single domain name apparently is not good for an entire registry. In other words, when faced with the prospect of putting one single domain name on hold, ICANN understands the rationale for requiring a review of the facts of the complaint—but when faced with the possibility of terminating an entire registry operation, Registry Operators are not afforded that luxury.

In fact, ICANN recommends just the opposite:

“If the registry operator fails to respond to the Complaint, it will be deemed to be in default and the allegations found in the Complaint will be deemed to have been sustained. The Provider will award an appropriate remedy in the event of a default.”

This means that even if a registry operator believes that a complaint is so frivolous on its face to even be taken seriously by any third party, that registry operator still needs to spend the time, money and resources to develop a comprehensive response, including the deposit of a substantial fee with the dispute provider. Otherwise, the registry operator will be sanctioned. Unlike the UDRP or URS, if the Complainant meets the procedural requirements in filing the complaint (meaning mostly that it has paid its refundable fee to the Provider), and the registry does not respond, there is no further review, but rather automatic remedies.

C. Disputes Based on Paper Alone

Yet another avenue that may reduce the burden for ICANN and the dispute providers, but that would actually result in a lower barrier for disputing filings, is the affirmative statement that “Disputes…will be resolved without a hearing unless, in the discretion of the Panel, extraordinary circumstances require a hearing.” The IRT did not opine on this particular subject, but did state at each of the consultations that they envisioned the PDDRP process to be comparable to a “mini-arbitration” that needed to be taken extremely seriously because it involves the potential of terminating an agreement in which a registry operator has most likely invested hundreds of thousands, if not millions, of dollars. Before ordering the potential termination of an entire registry, a registry should have the option of having a hearing. In other words, the hearing should be the default, not the exception.

IV. SUMMARY

For the reasons discussed above, and others which I have not yet had time to enumerate, I believe ICANN has missed some of the very critical aspects of the Post Delegation Dispute Resolution Process which balanced the interests of intellectual property owners and gTLD Registries. Although once an avid supporter of the policy, I now find ICANN’s interpretation and revision of the IRT proposal to be completely unacceptable. The IRT’s recommended approach was a compromise position that anticipated ICANN’s reasonable involvement in contract enforcement. If ICANN is not willing or able to shoulder that responsibility, I believe it raises serious and fundamental questions about the organization’s ability to effectively manage the introduction of new TLDs.

Surely one can understand why ICANN would like to extricate itself from this entire process and leave the enforcement to another third party. However, the time has come for ICANN to accept responsibility for enforcing its agreements and not rely on others to perform its work and make the tough calls. I call on ICANN to live up to its Affirmation of Commitments, to “provide a thorough and reasoned explanation of decisions taken, the rationale thereof and the sources of data and information on which ICANN relied.” It’s time go back to Square One with the PDDRP and produce a process that actually reflects the recommendations of the IRT Report and input from the community as a whole.

In closing, I would volunteer my time to assist with these efforts, and I hope to be taken up on my offer.

P.S. I hope it’s not lost on any of the readers of this paper that I work for a contracted party and am actually asking ICANN to enforce its agreements (which by implication would include our own).

By Jeff Neuman, Founder & CEO, JJN Solutions

He has been instrumental in providing policy assistance and advice in the fields of internet governance, intellectual property protection and domain name policy since the mid-1990s. Jeff has served in key business, policy and legal roles in the domain name industry for more than 20 years. The views expressed herein reflect my own beliefs.

Visit Page

Filed Under

Comments

How did ICANN morph from Midwife to Mother of the PDDRP? Thomas Barrett  –  Oct 8, 2009 1:24 AM

Jeff,

It looks like ICANN really messed up on this one.  Let’s hope they act fast and decisively to restart this effort.

There are two scenarios I can think of as possible causes of this mess:

1. ICANN has decided that it does not want to be in the role of contract enforcement or were captured by special interests

2. The staff assigned to draft this version are new to ICANN and poorly supervised

I don’t believe #1 is the case.  As you point out, ICANN now has a small army of people focusing on contract enforcement.  I’m sure they would be the first to say that contract enforcement remains part of their core mission. 

Plus, I always like to give people the benefit of having good intentions.  So, I suspect, scenario #2 is closer to the truth.

ICANN staffs’ job is that of a facilitator.  Wikipedia defines facilitator as “someone who helps a group of people understand their common objectives and assists them to plan to achieve them without taking a particular position in the discussion. The facilitator will try to assist the group in achieving a consensus on any disagreements that preexist or emerge in the meeting so that it has a strong basis for future action. The role has been likened to that of a midwife who assists in the process of birth but is not the producer of the end result.”

So, how did ICANN morph from Midwife to Mother of the PDDRP?

The problem is common to rapidly growing organizations that haven’t yet implemented formal control-and-command processes.  ICANN’s role of helping to build community consensus is a difficult one.  Few ICANN staff have prior work experience as facilitators and thus are learning these skills on the job.  Sometimes it is just easier [and faster] to go solo rather than go back to the community to reconcile conflicting input.  There is also the added pressure of publishing new drafts before the upcoming meeting.  This likely means that there is no formal internal team that reviews all the documents before they are published on the ICANN website.

There are some simple remedies:

1. All new staff should undergo facilitation training and be reminded that it is not their job to generate policy.  ICANN has the budget to implement this immediately.

2. ICANN should implement an internal review process to review all documents before they are published, to help ensure that #1 is strictly followed

3. Experience in facilitation and consensus-building should be required for future hires


Tom Barrett
President
EnCirca, Inc

Jeff - good article about a misbegotten Antony Van Couvering  –  Oct 8, 2009 6:42 AM

Jeff - good article about a misbegotten monstrosity.  Its appearance, especially in its new guise, stripped of the paltry safeguards that IRT proposed, seems to be lunacy.  What are they thinking?  What registry could do business under these conditions?  A registry has neither the competence, the authority, nor the means to police a zone in the way proposed. Does ICANN propose to indemnify a registry for refusing registrations because they’re afraid they might be a trademark?  It really passeth all understanding.

You missed a doozy in your critique, though - a single panelist could, on a whim, close a registry entirely, shut it down definitively.  So say the rules. WIPO would decide, and ICANN (and the ICANN community) would simply not matter.

Antony

I think you both raise excellent points Jeff Neuman  –  Oct 8, 2009 2:36 PM

I think you both raise excellent points and Antony your comment raises an issue that I took notes on but forgot to write about.  The IRT did recommend having a 3 person panel rather than just 1 for exactly the reasons you fear.  I will update this and my comments to the Forum when I find time.

Thanks.

Jeff,We're not bothered by the issue, we Eric Brunner-Williams  –  Oct 8, 2009 4:37 PM

Jeff,

We’re not bothered by the issue, we went from strong pre-del validation to post after two years with a registry we operate with only two DRP items or .5 x 10^^-5 DRP rate. We were also excluded from the IRT, a surprising outcome given our pre-IRT conversations with the IPC, however our focus is on implementable mechanism across multiple registry instances, by multiple platform operators, rather than a policy to be multiply independently implemented (maybe) by multiple registries and/or platform operators, so perhaps we gained by being ignored.

The IRT was a process hijack. ICANN staff is free to mangle it, like they mangle many other informed comments, and test their interpretation against more informed comments. The IRT ceased to exist, as was observed at the New York Consultancy, prior to that point in time, so the lack of consulting (your para 3 observation) seems unavoidable, at least with the authors of the Post Delegation Dispute Resolution Process, as an ensemble, though of course, all of those persons, yourself included, or in particular, given the registry consequence of the Staff’s formulation of the PDDRP, are trivially available.

I’m sympathetic to the claim that Staff bungled the PDDRP in v3. I’m unsympathetic to the claim that Staff lacked the responsibility to accept and modify the work product of the IRT, a responsibility which necessarily includes the possiblity of bungling even a proposal brought through a PDP rather than some other means.

Generalizing from the DRP issue at hand, to the general relationship between ICANN the contracting party and registries the contracting parties, the choice by Staff to place contract issues with third parties is a cause for concern. I support Tom’s reading of the tea leaves, and like you, appreciate that Anthony caught the lone gunman on the grass knoll.

This comment is being presented in my personal capacity and does not represent the views of my employer (CORE Internet Council of Registrars).

Eric,As usual, I am trying to decipher Jeff Neuman  –  Oct 8, 2009 5:31 PM

Eric,

As usual, I am trying to decipher what you are saying.  But be that as it may, I get the fact that you and others opposed the whole process for the creation of the IRT and our standing to make any recommendations.  I appreciate that…I really do.  But the fact is that I was not the one who decided who could be on the IRT or even what the role of the IRT was.  I was glad to be a member and glad to help out in any way that a could, but dont shoot the message simply because you disagree with the process the Board and IRT used. Look to the substance.

My point was that in justifying the PDDRP, in the very first line of the paper, ICANN staff states that “Several community participants, including the Implementation Recommendations Team (IRT). . . . have suggested….a [PDDRP]”.  It then goes on to completely rework and gut the entire IRT proposal, but making it look like these proposals actually came from us.  If they were truly basing their PDDRP on ours, then it should have been more explicit about what it did adopt and did not adopt and why (or why not)?  If it did not comprehend what we were saying or had any questions, it should have asked us.  As written, the ICANN staff paper makes it look like they are just presenting what we proposed and that could not be further from the truth.  ICANN should be acountable for this error.

If ICANN staff were to have said that something was based on a comment submitted by “Eric Brnner-Williams” and then went on to propose just the opposite, wouldn’t you want an explanation?  Wouldn’t you have wanted ICANN staff to call you before mangling what you wrote, but basing its justification on you.  Wouldn’t you want your name removed from the proposal?  Its the same thing here.  I was a member of the IRT, but the IRT did not propose what ICANN staff presented and therefore I believe that our names should be removed as the justification for the ICANN version of the PDDRP.  In fact, they are very different.

Glad to be opaque Eric Brunner-Williams  –  Oct 8, 2009 7:51 PM

Jeff,

Concern over process is not the same as concern over conclusion. The IRT could have been a midnight coven of witches who concluded that ICANN must make me Queen of the May. I might be pleased by the conclusion, probably not though, and I’d still be concerned by the process.

I really do look to the substance, and beyond the momentary policy differences that yield, in our case, a 1 in 25,000 ratio of DRP to registration instances, and for other operators, a substantially higher actual or latent ratio, to the means by which actors influence ICANN as a contract tendering entity, and independent of the means and actor, the ends, as even a monopolist has good competitive market public policy days.

As you know, both I and Amadeu support most of the findings of the IRT, independent of the process question, or the utility of presenting them as an indivisible lump, one unimplementable recommendation with several implementable, one awkwardly so, recommendations. I agree with your statement that the v3 PDDRP ain’t the IRTs PDDRP, but the ease with which the IRT presenters dismissed their collective consultative existance at the New York Consultation—“we reported and ceased to exist”—to paraphrase that moment, means that Staff couldn’t both change any element of the IRT’s work product and consult with a non-existant collective author on the sanity or correctness of that change. I really have no idea why the IRT members decided to take the position that their work couldn’t be used without modification, and that error in interpretation or modification could not arise.

I wish sponsor wasn’t so moribund. I wish escrow wasn’t so ... moribund too for that matter. I wish EPP weren’t so ... well, dead ended to use a different word for vitally challenged, and there’s an XRP in the NYC RFP someone didn’t white out. I wish community wasn’t so absurdly distant from linguistic-and-cultural. I wish ... ICANN’s done a pretty good job of mangling my junk, from Mike, Ester and Louis to the present moment (I check each version of the DAG to see if Catalan qualifies as a community).

Beer in Seoul?

This comment is being presented in my personal capacity and does not represent the views of my employer (CORE Internet Council of Registrars).

Crikey! Richard J Tindal  –  Oct 14, 2009 4:34 AM

Jeff,

Extremely well written article.  It captures the many, many flaws in this proposed PDDRP. 

I can ALMOST see the sense in the proposal if the string was something like .MICROSOFT and the operator was someone other than Microsoft Corp.  But in practice that won’t happen as no-one other than Microsoft will obtain .MICROSOFT.

What will happen is the registry for something like .SHOP will be plagued by frivolous and over-zealous claims from the numerous, worldwide holders of that mark. Worse,  the proposed rules indicate a complainant could successfully sanction the registry for taking open, second level registrations in something as generic as .SHOP.

It would be good to sit down with staff and see where this one came from.  On the vast majority of DAG issues I think the staff produced thoughtful and responsive proposals— but this one is a doozy of an exception.

RT

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

Related

Topics

IPv4 Markets

Sponsored byIPv4.Global

DNS

Sponsored byDNIB.com

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix

Threat Intelligence

Sponsored byWhoisXML API

Domain Names

Sponsored byVerisign

Cybersecurity

Sponsored byVerisign