[IOT] IOT Timing-Repose Issue

Thu May 11 06:55:47 UTC 2017

Here are some thoughts from ICANN regarding the statute of repose issue and, in particular, how the lack of a time limit could impact ICANN and the broader ICANN community:

The IRP IOT is discussing the issue of “repose,” which is has two components:

  1.  How long after a person is aware (or reasonably should have been aware) of a harm caused by an act of ICANN that was taken in contradiction to the Bylaws or Articles; and
  2.  How long of a period of time, in total, should pass before it is no longer reasonable for a person to claim they became aware of an action of ICANN that they alleged caused them harm?

The first question has been settled among the IRP IOT, that a 120-day period from becoming aware of an action is a sufficient time for filing.

On the second question, the IRP IOT is considering modifying the proposal posted for public comment, which imposed a 12-month outer limit, from the date of ICANN’s action giving rise to the IRP, on when it is reasonable for a person to become aware of and challenge that act. See Draft Rule No. 4.  Some on the IRP IOT propose that there should be no time limit on the ability to claim that an act of ICANN violated its Bylaws or Articles.  ICANN has been asked to provide information on how the lack of a time limit could impact ICANN and the broader ICANN community.

During the public comment period, one group (Linx) offered the following example to support its view that the proposed “statute of repose” would unfairly deprive claimants the opportunity to access the IRP:

Let us suppose that ICANN … adopts the following policy:

No domain name shall be used to advance Little-Endian beliefs or practices. All Registry Agreements shall be amended to require all Registries to suspend or cancel domains that have been used for that purpose.

Such a policy would be a blatant violation of Section 1.1(c) of ICANN’s bylaws, which prohibit ICANN from seeking to restrict Internet content.
In this example, according to Linx, “a particular party … might not themselves be directly affected by the policy for many years, before finally themselves being told that their domain is forfeit for violation of the policy.  During this interim, they will be precluded from challenging ICANN’s blatant overreach.”  In the example, the suggestion is raised that this could be as many as ten years after the adoption of the policy, based on the ability to have long periods of renewal for domain names.

This situation as proposed by Linx, however, describes a wholesale failure of the ICANN system, where many opportunities existed for challenging an act outside of mission before the party in the example becomes aware of the act outside of mission. There are other questions that could accompany the evaluation of whether access to the IRP ten years down the road is an important element of accountability: How does the invocation of an IRP ten years down the road further the purposes of the IRP, including efficiency in action? What is the intended outcome ten years down the road?  Are there other ICANN accountability mechanisms that are also applicable? What protections apply to make sure that the dispute is only about items that were contrary to the Bylaws/Articles at the time the action was taken by ICANN?

In this example, using today’s Bylaws, here are the things that would have had to occur over a period of at least a year (and in reality, far more than that) in order for a policy against mission to have been adopted and implemented:

  1.  Proper support in the GNSO for the issuance of an issue report on an item outside of mission, without challenge.
  2.  General Counsel determination that the issue was within mission, as included in the issue report.  Determination not challenged (eligible for challenge under the IRP).
  3.  The two houses of the GNSO would have to agree to initiate a policy development process, without challenge.
  4.  Conclusion of the PDP process, and the required public comment on the policy recommendations, without challenge.
  5.  Passage by both houses of the GNSO – each by at least a majority – in order for recommendations to go to the Board. (NOTE: the example here suggests that this is a consensus policy applicable to existing registries and registrars, so a higher threshold is required).
  6.  Public comment on the policy recommendations prior to Board approval.
  7.  Board approval of the policy recommendations (eligible for challenge under the IRP).
  8.  After work to craft implementation, a directive from ICANN to contracted parties to implement the policy (eligible for challenge under the IRP).[1]

As seen in the above, there are three separate times when ICANN takes an action that could serve as the basis of a dispute.  So in the example, the third and final claimant limitations period would begin at the time of ICANN’s directive to implement the policy, even if this happens years after the initial scoping or the Board approval of the policy recommendations.[2]

If all of these milestones were able to pass without challenge from any part of the ICANN multistakeholder community, whether or not an IRP is available ten years down the road does not seem to provide much of a solution to a wholesale failure of accountability within the multistakeholder process.  While there is not value in allowing an act in violation of the mission to stand, basing the argument that there should be no time limits for an outside limit on challenge of specific actions on an example of systemic failure does not seem to be solving for the correct issue.

Removing any time limit within which the ICANN community can count on the finality of an action could have impacts on the community.  A more realistic example could be:

Example: A person or entity decides that a provision in an agreement within a Registry or Registrar contract has caused them harm and is in violation of the Bylaws or Articles.  The Registry has been operating under this term for any number of years, and no prior complaints have been received.  The issue is not straightforward, and determining if a Bylaws violation has occurred requires a significant fact-finding effort.  Because of the time that has passed, most or all of the people within ICANN familiar with the development of that provision are no longer with the company.  The documentation on the development of that provision is difficult to find, or is no longer kept due to appropriate organizational document retention practices.

How would this impact an IRP?  Some thoughts:

  1.  Cost: the longer it takes to challenge an action, the more expensive it can be to identify the appropriate documentation.
  2.  Time: Relying on stale information and incomplete memories could increase the time the fact finder (IRP panel) needs to perform its work.
  3.  Consistency and coherence: At risk of not having a full record to support the proceeding, the consistency and coherence of the outcome of the binding IRP are at risk.

As Linx stated in its comment: “It would be potentially legitimate to adopt a time bar if it could show that allowing claims to be filed any later would reduce fundamental fairness and undermine due process, contrary to Section 4.3(n)(iv).”

What happens if the IRP declares ICANN’s entering of the contract was a violation of the Bylaws?

  1.  Is the whole contract voided, or only the part at issue?
  2.  What if the challenged language is within other agreements/part of the model agreement text?
  3.  What happens to others impacted by the same action before it was challenged?

The questions raised on the “what happens” would have to be faced at any time that ICANN’s entering of a contract is challenged in an IRP.  However, they outline the importance of efficient resolution of disputes raised within an IRP.  Answering these questions is clearer when only one year has passed, as contemplated by the Supplemental Rules as posted for comment.  Those holding the contracts or relying on the contracts are on notice that there is a potential issue before too long of a period has passed.  If years have passed, the agreement at issue could have been long relied upon as representing settled standard operating procedures. The longer a period of time that the contract has been relied upon as settled, the more difficult the process to unwind.

Unwinding agreements years later on information that is at risk of being incomplete could instead be seen to decrease ICANN’s accountability to the broader community, as opposed to enhance it.  Eliminating the period of repose in its entirety does not appear to promote the purposes of the IRP.

The IRP is one of multiple accountability mechanisms that are available to the ICANN community.  While the IRP is an avenue to achieve a binding determination of whether ICANN is acting consistently with its Bylaws and Articles, but it is not the only way to raise issues and try to achieve a just and fair result and predictable action from ICANN.

As noted in a prior communication to the IRP-IOT, ICANN does not agree that there is any inconsistency with the Bylaws to require an outside limit on when it is appropriate to challenge and action through IRP.  On the contrary, failure to impose any limitation could subvert the purpose of the IRP and the multistakeholder community’s ability to rely on ICANN’s actions as final.

--
Elizabeth Le
Senior Counsel
elizabeth.le at icann.org<mailto:elizabeth.le at icann.org>
310-578-8902 (direct)
310-745-7767 (mobile)
310-823-8649 (fax)
elizabeth.le.ICANN (skype)

ICANN | Internet Corporation for Assigned Names and Numbers
12025 Waterfront Drive, Suite 300 | Los Angeles, CA 90094

________________________________

[1] If the implementation of a policy calls for a violation of the Bylaws or articles, the implementation is not insulated from IRP solely because the policy itself was approved.  Implementation is a separate action by ICANN that gives rise to an IRP.

[2] See Draft IRP Updated Supplementary Procedures: Report of the IRP IOT, Oct. 31, 2016, at 3 (“[A]ctions or inactions giving rise to an IRP claim can occur more than twelve months following the adoption of a particular rule.  For example, were ICANN to interpret a policy in a manner that violated the Bylaws, the time period would run from the date on which the offending interpretation occurred, not the date on which the policy was adopted.”).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/iot/attachments/20170511/85ea3afb/attachment-0001.html>