[IOT] REMINDER - IRP IOT at 5:00 UTC Wednesday 7 Aug

Malcolm Hutty malcolm at linx.net
Tue Sep 6 23:15:56 UTC 2016

On 06/09/2016 19:32, Burr, Becky wrote:
> I am re-attaching the documents circulated last week for discussion.  I
> know this is not an ideal time for many of you – so If you are unable to
> attend the call, please let us know your views on the 3 open issues.


I remain uncomfortable about the time bar. I'm afraid I won't be up at
5am to discuss this, and was just heading to bed, so I will put down a
marker for some core points.

1. My top concern is that Complainants should not be denied the
opportunity to challenge an allegedly improper action (especially, a
policy that is facially ultra vires the Mission limitation) merely
because the policy was adopted a long time before it directly affected
the Complainant.

This is therefore really a concern about when the clock starts running.

2. Becky, you had previously drawn a distinction between Disputes
similar to those permitted in the past, which were allegations of
procedural irregularity in which disputed facts were important, and
Disputes of a substantive nature, where the allegation is that the
action is facially invalid (again, the obvious example being "What ICANN
is doing is outside this Mission" or "What ICANN is doing is an
illegitimate discrimination/favouritism/disparate treatment").

I think this is a very helpful and important distinction.

Rather than arguing about the length of the bar, while holding in our
own minds example scenarios in completely different categories to each
other, perhaps we should consider limiting the time bar to the former
category i.e. to cases (or arguments) concerning procedural
irregularities, and excluding (i.e. allowing the IRP to decide) whether
an action is facially improper/ultra vires.

There is no time bar for an allegation that a law that remains in force
is contrary to the US Constitution or the European Convention on Human
Rights. Should ICANN not also face similar accountability? Perhaps our
task should focus on crafting a workable distinction, rather than
pondering times.

3. Separately, I think the 45 day limit is unjustifiably short. Why are
we picking such a short time, rather than, say, one or three or five years?

You previously mentioned the risk of problems when time causes memories
to fade, staff move jobs etc. I think these are the sorts of problems a
time bar should be dealing with - and if that is the issue, we should be
thinking in terms of "many months" or "small numbers of years". I don't
think the time bar should be used simply to provide ICANN with greater
certainty by immunising it from challenge at the earliest possible date.
The Bylaws guarantee the right to challenge; this shouldn't be
subverted, and I think we are in danger of doing that.

4. We haven't given any thought to how the 45 day bar limits the
opportunity to conduct a sensible dialogue with ICANN prior to
committing to litigation. Indeed, there is supposed to be a formal
Cooperative Engagement Process. Is the Complainant supposed to file an
IRP, then start the CEP? Or do the CEP, then file? If the latter, I'm
not aware a CEP has ever been as short as 45 days. At the very least,
our rules should clarify this.

5. What about Community IRPs? Are we seriously expecting the Community
Process, with all that it entails, to be conducted and reach a
conclusion that is capable of being exercised as a formal filing, all
within 45 days? I must say, if the community process ever worked so
swiftly, I would be amazed.

6. Nor do I see that as unique to the Community IRP. While certain IRP
complaints might be "traditional", in that they only affect a particular
party who is already engaged with ICANN, some may not match that
pattern. There might be an entire class of people affected, and they
would need to determine representation. I'm not talking about a US-style
"class action", but if many are affected some form of combination, joint
action or representation-in-effect may be needed.

Consider, for example, if the Complaint implicates the interests of all
those who have intellectual property in recorded music. Even though this
is an industry that is extremely well prepared for litigation in defense
of its rights, there is a huge range of *types* of enterprises (artists,
publishers, labels, lyricists and so on seemingly ad infinitum), never
mind individual companies. All this implies a reasonable requirement for
reasonable time for coordination to present a challenge that properly
reflects the nature of the complaint.

If we think of a less litigious industry - bakery for example - I
suspect they will be utterly excluded from the protection of IRP at this
kind of timeframe.

7. Another issue relates to the question of how we know whether the
clock has started. How does one actually file an IRP? Is there an actual
form? Is mere notice to ICANN of a complaint sufficient?

Given that ICANN has so far failed to establish a standing panel, the
prospective Complainant seems to be left rather in ICANN's hands. This
seems to leave a possibility for confusion or disagreement as to the
date when filing was made.

What happens if there is disagreement as to whether an IRP Complaint was
filed in time? Does the IRP panel itself determine this question? Or can
ICANN declare that a filing is out-of-time, and suppress it?

I suggest our rules should clarify that the IRP is the arbitrator of the
application of its own rules.

I hope you find these comments helpful. I fear they open up new areas,
suggesting we are not yet ready. But as things stand, I have a greater
fear that ICANN would not be able to defend the adoption of such a time
bar, if these rules were themselves the target of an IRP challenge.


            Malcolm Hutty | tel: +44 20 7645 3523
   Head of Public Affairs | Read the LINX Public Affairs blog
 London Internet Exchange | http://publicaffairs.linx.net/

                 London Internet Exchange Ltd
           Monument Place, 24 Monument Street London EC3R 8AJ

         Company Registered in England No. 3137929
       Trinity Court, Trinity Street, Peterborough PE1 1DA

More information about the IOT mailing list