[Gnso-igo-ingo-crp] Reviving Option #5

George Kirikos icann at leap.com
Sat Nov 18 15:49:02 UTC 2017


Hi folks,

In yesterday's email to this mailing (below), I used the metaphor of a
"software bug". It prompted further analysis of one of the options of
a few months ago that had been abandoned as infeasible previously,
namely Option #5 from Paul Keating, see:

http://mm.icann.org/pipermail/gnso-igo-ingo-crp/2017-July/000784.html
http://mm.icann.org/pipermail/gnso-igo-ingo-crp/2017-July/000785.html
http://mm.icann.org/pipermail/gnso-igo-ingo-crp/2017-July/000786.html

As you'll recall, Paul Keating identified an asymmetric certification
requirement under the UDRP rules by the parties. That was a very keen
observation. As he suggested, if indeed that asymmetry existed, then a
domain name registrant (respondent in a UDRP) could name the ADR
provider (WIPO, NAF, etc.) in a court action, because the UDRP
certification requirement didn't actually shield the ADR provider
properly (unlike the complainant's certification).

In my followup emails (the 2 latter links above), I noted that the
UDRP providers prevented that scenario, because they "fixed the bugs"
so to speak, eliminated that vulnerability, via their own supplemental
rules.

So, my question is, why should those supplemental rules be permitted at all?

Advocates of Option C clearly do not believe that this PDP should
actually eliminate bugs in the UDRP (i.e. they oppose Option A, which
would eliminate the bug in the policy). If we're not allowed to fix
that bug (even though that should be our mission, and the GNSO is the
proper policymaking body for ICANN), then why should UDRP providers be
allowed to fix bugs that they identify and impact them? It would be
hypocritical to apply one standard to certain "bugs" in the UDRP, and
a different one to other bugs.

ADR providers should be forced to live by the strict application of
the UDRP rules as written, warts and all, and not deviate from them by
imposing their own supplemental rules that completely fix the problems
for themselves.

So, WIPO's paragraph #15:

http://www.wipo.int/amc/en/domains/supplemental/eudrp/newrules.html

"15. Exclusion of Liability

Except in respect of deliberate wrongdoing, an Administrative Panel,
the World Intellectual Property Organization and the Center shall not
be liable to a party, a concerned registrar or ICANN for any act or
omission in connection with the administrative proceeding."

which they used to fix the "bug" in the UDRP that exposed them to
liability from the Respondent of a UDRP should be deemed invalid, and
similarly for other UDRP/URS providers.

By doing so, this fully revives Option #5, and puts it back on the table.

As an aside, WIPO might believe that their immunity as an IGO might
still shield them from a lawsuit from a domain name registrant
involved in a UDRP, if we required strict adherence to the UDRP rules
(and disallow those supplemental rules fixes). However, I believe this
would not be the case, because when they're acting as an ADR provider
it should fall under the "commercial exception." (the fact that they
added the language to the supplemental rules supports that view; if
they believed they were fully immune, they wouldn't need to have added
it)

Sincerely,

George Kirikos
416-588-0269
http://www.leap.com/

On Fri, Nov 17, 2017 at 7:36 PM, George Kirikos <icann at leap.com> wrote:
> Hi Petter,
>
> On Fri, Nov 17, 2017 at 6:22 PM, Petter Rindforth
> <petter.rindforth at fenixlegal.eu> wrote:
>> And all WG members had (and have) their freedom to further explain and argue their support for a specific solution/option. As you say George, sometimes a support for one specified option needs more detailed explanation, where other options may be more clear, "fair and balanced".
>
> Those are not valid arguments, just to say they're "fair and
> balanced", without explanation (with reference to facts and law).
>
> Let me abstract away from domains and ICANN for a moment. Imagine
> we're tasked to look over software for an airplane, a purely
> technical/engineering endeavour. In our review, looking at something
> else entirely, we come across a critical vulnerability that could
> cause the plane to crash under some rare circumstances. What would we
> do? Logically, we'd fix the code so that the plane would never crash
> under that circumstance, period.
>
> This is what our job was in this PDP. We were to look at the all the
> law, facts around IGOs, immunity and the UDRP, and thoroughly research
> the topic. During that review, we discovered there was a "critical
> vulnerability" in the UDRP itself. Rather than being an airplane
> crash, this vulnerability is that some domain name registrants would
> be denied the ability to have their day in court, to have their case
> decided on the merits "de novo" (if an IGO successfully asserted an
> immunity defense after winning a UDRP).
>
> That's all it is --- a "software bug" under some scenarios. The
> designers of the UDRP hadn't ever contemplated that scenario in 1999.
> Because we did such a thorough job in our research, far better than
> what happened in 1999, we're in the best position to decide how to fix
> the "software bug."
>
> Option A is a complete technical fix to the "software bug". The domain
> name registrant can have their day in court. If the IGO wants to press
> the matter, they have to give up the immunity, importantly, ****just
> like they would have to do had the current UDRP not created the "bug"
> in the first place*****. (re-read that part between the asterisks --
> that is critical) Or the IGO can use one of the workarounds we
> identified to completely insulate themselves from the immunity
> issue/risk (agent, assignee, licensee brings the action, thereby
> shielding the IGO). The IGO is in the best position to mitigate (if we
> did the proper Risk Analysis I've called for). The domain owner is in
> no position to mitigate.
>
> So, suppose prior to Option A, the "plane crash" might happen 10 times
> in the next 100 years. Under Option A, it happens zero times. The
> problem is solved. The solution perfectly mirrors a world without the
> UDRP --- both parties are in the exact same legal position as if the
> UDRP hadn't happened. A level playing field is maintained, and any
> rights that exist in the real world are fully respected under Option
> A. No one's rights have been interfered with.
>
> Now, those backing Option C say "Well, we'll implement a so-called
> "fair and balanced" solution that makes the plane crash happen just 5
> times in the next 100 years. "Yippee" they say, we've made an
> improvement! Their frame of reference, their "starting point" isn't
> "zero crashes" -- their focus was a world *with* the bugs, a world of
> "10 crashes per 100 years" as the "status quo".
>
> Yet, the plane still crashes under Option C, and supposedly we should
> be willing to "accept that". Under Option C, it is entirely possible
> for an arbitration panel to rule differently than the courts would
> have ruled in a dispute. That's undeniable, because they are by
> definition different. Option C is a poor facsimile of real court. The
> domain name owner is *entitled* to court access, the real thing. No
> one has the UDRP or arbitration as an "entitlement" -- it's a bonus
> that is entirely supposed to be negated if one goes to court. Going to
> court is supposed to "reset things" and have a level playing field
> where everything is supposed to be decided under real laws.
>
> Option B, to continue the story, says "We'll fix the code completely
> for existing planes. New planes can get the "fair and balanced
> solution" pushed by Option C's partial fix. So, perhaps now, planes
> would crash only 2 times in the next 100 years (0 crashes for old
> planes, though, and all the crashes on the new planes). Those who fly
> on new planes have that choice, if they want to take the risk, they go
> into it with eyes wide open.
>
> Option #6 would have been similar in nature, in that it tries to
> reduce the number of plane crashes (by making it harder to get to the
> "crash scenario" computer code, kind of filtering the scenarios
> somewhat). So, instead of crashing 5 times per 100 years under
> existing Option C, it'd be a lower number if Option #6 was integrated
> into a new Option C, maybe 3 times per 100 years.
>
> I hope that helps folks look at things in a different way. Folks like
> myself who are convinced Option A is the correct solution cannot
> understand why those backing Option C are willing to accept those
> "plane crashes" at all! We're not here to play politics and say "well,
> we made an improvement, we did the best we could". We're supposed to
> be here to analyze all the facts, knowledge, law, and analysis to get
> to the correct decision (Option A).
>
> I leave Option C backers with this question --- do you acknowledge
> that under Option C, arbitration panels might make different rulings
> than a court would??? Yes or no.
>
> If the answer is "Yes", explain to us why that should be acceptable to
> domain name registrants?
>
> A domain name registrant, who is entitled to the protection of their
> national courts, should not lose the right to that court access,
> simply because the UDRP was not coded properly in 1999 and contains
> software bugs. It should be our duty to fix the problem, eliminate the
> software bugs,  rather than knowingly keeping a smaller or different
> bug still lurking in that code (a bug that might have further
> unintended consequences down the road that we haven't contemplated yet
> that others might exploit).
>
> Notice, I'm asking very simple questions here that cut to the heart of
> the issues, yet instead of any answers, some are playing political
> games, saying "well, we made a potential small improvement, you should
> be happy, that's all you're going to get".
>
> Sincerely,
>
> George Kirikos
> 416-588-0269
> http://www.leap.com/
>
> P.S. This "immunity" issue  isn't the only "software bug" in the UDRP.
> As some of you know from our RPM call on Wednesday, I talked about the
> other "bug" whereby some courts (e.g. in the UK) are refusing to hear
> de novo reviews/appeals of UDRP decisions at all, e.g. see the
> Yoyo.email case:
>
> http://www.bailii.org/ew/cases/EWHC/Ch/2015/3509.html
>
> "My conclusions on the application to strike out the Claim are:
>
> 1) adopting the reasoning of Ms Proudman in Patel drives me to hold
> that on a proper construction of the UDRP clause 4k does not give rise
> to a separate cause of action in favour of the claimant;
>
> 2) nor does it afford any jurisdiction to this Court to act as an
> appeal or review body from the Decision;"
>
> This is clearly something the UDRP drafters in 1999 never
> contemplated, and is a software bug we'll have to deal with in the RPM
> PDP, as it strikes at the very bargain that was made when the UDRP was
> adopted, namely that it wouldn't interfere with legal rights on access
> to the real courts for a decision on the merits. For it to happen in
> some jurisdictions wasn't known by those drafting the UDRP. (also
> applies equally to URS)
>
> I'll be writing more about that "software bug" in the RPM PDP's
> mailing list probably next week.


More information about the Gnso-igo-ingo-crp mailing list