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] <mailto:[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]
> <mailto:[log in to unmask]>>
> Cc: Milton L Mueller <[log in to unmask] <mailto:[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
> <tel:%2B44%2020%207645%203523>
> Head of Public Affairs | Read the LINX Public Affairs blog
> London Internet Exchange | http://publicaffairs.linx.net/
> <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
>
>
>
|
