These are great questions you are raising, Tamir, and I started raising some of them in my own mind as I was attempting to draft comments for NCSG on this problem.
What you are really suggesting is that by trying to contractually enforce these kind of restricted TLDs, ICANN actually does get itself into various forms of service regulation, and that it would be hard to draw the line between
Here are the comments I have made on this topic so far, your advice and rewordings are welcome (and this is directed to the entire list)
One of the most important accountability enhancements is to narrowly define ICANN’s mission and commitments, and to give the Independent Review Process the ability to bind ICANN
to those commitments and to enforce ICANN’s compliance with a well-defined, limited mission. While that goal does command broad consensus, the CCWG has made some mistakes in implementing it. We find two areas of concern: the comment in paragraph 158 concerning
so-called “freedom to contract” and paragraph 224 related to advice from public authorities.
The ICANN commitment in paragraph 187 says:
"ICANN shall not engage in or use its powers to attempt the regulation of services that use the Internet's unique identifiers, or the content that they
carry or provide."
This is a very good, strong limitation on ICANN and NCSG supports it. But in the Second Draft Report, paragraph 158 provides commentary on this ICANN commitment that completely
contradicts the intent and purpose of paragraph 187.
The ICANN commitment in paragraph 187 was inserted to make clear that ICANN could not use its contracting power with Registries and Registrars as a lever to engage in general
regulation of Internet content and services. And yet paragraph 158, under the heading “Freedom to Contract,” says the CCWG:
“...concluded that the prohibition on regulation of services that use the Internet’s unique identifiers or the content that they carry or provide does
not act as a restraint on ICANN’s contracting authority.”
This formulation is poorly stated and must be changed in any final proposal. Since ICANN’s regulatory powers are exercised exclusively via contract, the prohibition on regulation
of services and content does - and must - act as a restraint on ICANN’s contracting authority. The whole purpose of paragraph 187 is to prevent ICANN from using its contractual authority over domain names to engage in general regulation of Internet
content and services. What the CCWG discussions about this actually concluded was that the commitment in 187 would not prevent ICANN from enforcing compliance with a specific TLD registry’s own commitments to offer a certain type of service in its application
for a delegation. Contractual obligations to ICANN in these types of cases would only apply to a specific TLD operator (e.g., .bank) based on commitments that it made on its own initiative (e.g., to restrict registration to certified financial institutions).
NCSG believes that the heading “Freedom to Contract” is much too broad a title and must be changed to “Compliance with voluntary commitments.” The last sentence should be modified
to read: “...the prohibition on regulation of services that use the Internet’s unique identifiers or the content that they carry or provide does not prevent ICANN from using its contracting authority to enforce compliance with policies that are within ICANN's
Mission." The omission of this qualification at the end of paragraph 158 is confusing and potentially dangerous and must be addressed before NCSG can accept the proposal.
NCSG is also concerned about paragraph 224, which also seems to undermine ICANN’s commitment to a narrow mission. In this Principle, ICANN commits itself to recognize that “governments
and public authorities are responsible for public policy and duly take into account the public policy advice of governments and public authorities.” The prior version of this language said that ICANN would take governmental advice into account, but qualified
it with the statement that it would react to such advice “in accordance with the bylaws and to the extent consistent with these fundamental commitments and core values.” NCSG believes that it was a serious mistake to delete that language. It is essential
that ICANN only act on advice that is consistent with its narrow mission, fundamental commitments and core values. As originally worded, this commitment did not prevent GAC or any other government from offering any advice to ICANN that it wished. It did, however
express ICANN’s commitment not to act on that advice if it was inconsistent with its mission, commitments and core values. Now that restraint is gone. If “advice from public authorities” constitutes a get-out-of-jail-free card for the ICANN board, then ICANN
can do anything, including abuse its powers and break its own bylaws. Note that the current language does not even specify that the advice ICANN will ‘duly take into account’ must be formal consensus advice from the GAC. Apparently, any public policy advice
from any public authority or government will do. This is not an enhancement of ICANN accountability but an abdication of it.
The
From: Tamir Israel [mailto:[log in to unmask]]
Sent: Friday, August 21, 2015 11:26 AM
To: Mueller, Milton L; [log in to unmask]
Subject: Re: FW: FW: "Limitations on ICANN's contracting authority."
Dear Milton,
Thank you kindly for forwarding this.
It raises 2 points, I think. First, if the explanatory note says something very different from the actual provision, then that should be an easy fix. It should say that ICANN can use its regulatory infrastructure to enforce contracts entered into between registrars
and other parties even if those contracts regulate content in some manner. Leaving it as is can lead to problems down the road.
But second of course is the question of whether it's appropriate for ICANN to do so, or whether such disputes are best left to other regulatory mechanisms. I can see arguments on either side, but much of it would depend on the scope of the intended exception.
Take the relatively innocuous .bank example. Are we saying that ICANN can prevent registrars from pulling the rug out from under regsitrants through a contract change that affects content? (After 10 years of operation, .bank removes the obligation on registrants
to be financial institutions). That might be ok, and doesn't really get too deep into content issues. But are we also saying that ICANN can adjudicate on Registrar-registrant contracts that affect content? Ie can I complain to ICANN that my bitcoin.bank was
refused? Can Bank of America complain to it because my bitcoin.bank was accepted? Can states have ICANN ban questionable payment intermediaries from .bank because these states believe are funding rogue operations like wikileaks? The latter seems potentially
more problematic, because then we're leaving it to ICANN arb panels to determine what a 'bank' is, which is precisely what the prohibition on content is trying to avoid.
Not sure where this process is at, but I think it might be worthwhile to get some clarification on these points.
Best,
Tamir
On 8/20/2015 4:45 PM, Mueller, Milton L wrote:
See Malcolm’s discussion below, which clarifies a lot.
However, I do not agree that we can rely entirely on the proposed bylaw change (which is actually paragraph 187 in the proposal, not paragraph 188).
I think we should make an issue of this in our comments and insist that the language “"provided,
of course, that the policy itself being enforced contractually is one that lies within ICANN's Mission" be included in the final proposal
--MM
From: Milton Mueller [mailto:[log in to unmask]]
Sent: Thursday, August 20, 2015 3:34 PM
To: Mueller, Milton L <[log in to unmask]>
Subject: Fwd: FW: "Limitations on ICANN's contracting authority."
---------- Forwarded message ----------
From: Malcolm Hutty <[log in to unmask]>
Date: Wed, Aug 19, 2015 at 2:04 PM
Subject: Re: FW: "Limitations on ICANN's contracting authority."
To: Paul Rosenzweig <[log in to unmask]>
Cc: Milton L Mueller <[log in to unmask]>
On 19/08/2015 17:50, Paul Rosenzweig wrote:
>
> I’ve exceeded my understanding of this issue – do you have anything to
> add that might assist in the discussion.
I can explain the history of this text, if you like.
As Milton says, the language
"Without in any way limiting the foregoing absolute
prohibition, ICANN shall not engage in or use its powers to
attempt the regulation of services that use the Internet's
unique identifiers, or the content that they carry or
provide."
was inserted precisely to make clear that ICANN could not use its
contracting power with Registries and Registrars as a lever to engage in
general regulation of Internet content and services.
The concern that ICANN might one day try to do this, and should be
restrained from doing it, was recorded in Stress Test #23.
When this proposal was put out for the First Public Comment, the CCWG
received input from some commercial stakeholders that expressed concern
that this would interfere with the existing Contract Compliance
programme. From memory, the stakeholders who raised this concern were
members of the Business and Intelletual Property constituencies, and the
Business Constituency itself supported this intervention.
This prompted a discussion within the working party: what exactly were
these stakeholders worried about? Did this intervention mean that they
wanted ICANN to be able to regulate content and services generally?
Steve Delbianco, on behalf of the Business Constituency, offered the
example of .bank: as part of the creation of that TLD, it was proposed
by the prospective registry that only registered banks would be allowed
to register within that domain. This would form part of the Registry
agreement, and the successful Registry would not be allowed to change
their policy later and turn .bank into a free-for-all open registration
policy domain. Should they try to do so, ICANN would enforce the
Registry agreement, even though the restriction on registration in .bak
originated not in an ICANN PDP policy, but in the voluntary proposal of
the gTLD applicant. Steve said that the Business Constituency wanted to
ensure that this enforcement would continue, and that the abovementioned
text in the Bylaws should not prevent ICANN from stopping the Registry
from changing its policy on registration after the TLD's initial delegation.
(Some of) those that had proposed the abovementioned text responded that
this was not intended to interfere with that behaviour by ICANN. They
drew a distinction between using the Registry contract to enforce the
terms on which the initial delegation was made, and introducing new
policies intended to regulate the behaviour of end-user registrants.
They (we) argued that defining the purpose of each gTLD, and creating
policies so that those gTLDs achieved their purpose, was clearly within
the scope of ICANN's proper Mission. Accordingly, enforcing those
policies through ICANN's contracting power remains within ICANN's
authorised powers. By contrast, if it were to create new policies to
which registrants must aide, not for the purpose of defining the scope
of a given domain, but with the intention of controlling user behaviour
generally - that is, justified not by the need to ensure an open,
interoperable, reliable and secure DNS but by its conception of the
public interest more broadly, then that would indeed be outside ICANN's
Mission and this clause would indeed restain ICANN from using its
contracting authority in that manner.
Accordingly, we argued, the concern raised by the Business Constituency
was unwarranted: this clause would not act as a restain on ICANN's
contracting authority as a means of enforcing ICANN's policy - provided,
of course, that the policy itself is one that lies within ICANN's
Mission. It was agreed that a note to this effect would be made in the
Second Public Comment draft, and that this would be given as the reason
why we had not changed the text to which some stakeholders objected.
That is how paragraph 158 came about.
In my view the omission of this last qualification in paragraph 158 of
the public comment is indeed confusing (i.e. the omission of "provided,
of course, that the policy itself being enforced contractually is one
that lies within ICANN's Mission"). I can see how, lacking this
qualification, the paragraph gave rise to Milton's "WTF moment".
However, this is only explanatory text: the draft bylaw language is
paragraph 188. The only real concern I would have would be if the
lawyers, working from paragraph 158, sought to redraft paragraph 188.
I hope that helps,
Kind Regards,
Malcolm.
--
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
21-27 St Thomas Street, London SE1 9RY
Company Registered in England No. 3137929
Trinity Court, Trinity Street, Peterborough PE1 1DA