[CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

[Malcolm Hutty]

On 19/01/2016 03:32, Greg Shatan wrote:
> 
> ​If (in your view) ICANN ca​nnot enforce obligations that an applicant
> includes in its application, who can enforce those obligations?

Greg,

By calling them "obligations" you presuppose the correctness of your own
position that ICANN should enforce them. Let us call them what they are:
"statements concerning how the applicant intends to operate the Registry".

Are all such statements obligations? Clearly not: the contract does not
govern every aspect of registry operation; plenty of decisions are left
to the commercial policy of the applicant, which it is free to alter
over time.

>  If no
> one can enforce these obligations, then how can they even be called
> obligations?  

They should not be. Please stop doing so.

> What keeps applicants from pulling a "bait-and-switch,"
> stating a series of "obligations" in their application, only to drop
> them after the application is approved.

The notion of "bait and switch" implies that there is a bait. In my
view, ICANN should not regard as bait a promise to engage in an
enterprise that ICANN has no legitimate right to pursue. Indeed, it
would make sense in the next round to amend the applicant guidebook /
application form in a way that strongly discourages applicants from
offering up promises that ICANN ought to disregard.

> Frankly, I think it is entirely within ICANN's mission to enforce
> obligations set out in applications.  

Again, there you go pre-supposing the validity of your claim. Merely
because something is written into an application doesn't make it
something that ICANN must go along with. (If it does, I'll be submitting
an application containing an "obligation" on me to receive a regular
income from ICANN!). For something to be an obligation, it must be
something that becomes part of the contract. ICANN should not be willing
to write into its contracts objectives that it has no right nor interest
to pursue.

As part of its Mission to implement policies for which uniform or
coordinated resolution is reasonably necessary to facilitate the
openness, interoperability, resilience, security and/or stability of the
DNS, ICANN may indeed enter into and enforce contracts to achieve those
ends. It may not, however, enter into and enforce contracts entirely
unconnected with those ends, or designed to pursue ends in conflict with
its Mission and Bylaws.

>     It shouldn't be surprising that ICANN cannot escape the limits of its
>     Bylaws simply by placing something inconsistent with them into a
>     contract. 
> 
> 
> ​However, this is not what Becky postulated.  She postulated obligations
> ​placed in the agreement by the registry operator, not obligations
> placed in the agreement by ICANN.  

There is no difference. A contract is an agreement. It is a joint
enterprise, with both sides jointly engaged in the purpose of the
contract (albeit, often with different tasks to undertake in pursuit of
that enterprise).

If the contract says "We will censor all mention of llamas from any web
sites run on domains within this domain", then both the Registry and
ICANN are engaged in the enterprise of suppressing mention of llamas.

That it is the Registry's task in pursuit of this enterprise to send
notices to registrants instructing them to remove articles mentioning
llamas, and ICANN's task to consider whether the Registry has been
sufficiently dilligent and effective at suppressing talk of llamas, are
mere points of detail. In their respective roles, both ICANN and the
Registry are llama-suppressors.

>     If a Registry placed something in its application that would,
>     if agreed, cause ICANN to act inconsistently with law that was
>     applicable to ICANN, you wouldn't expect the contract to override
>     applicable law. Nor should it override the governance of ICANN.
> 
> 
> ​This answer only muddies the waters. We seem to have shifted somehow
> from potential obligations placed on the applicant to potential
> obligations placed on ICANN in the application that would then become
> part of the RA. I'm not sure where that shift came from. 

There is no shift. The contract is a joint enterprise.

Consider the following illustrative example. Suppose that an applicant
said that they would operate their domain on a not-for-profit basis, and
that any surplus accumulated in excess of operating requirements and a
prudent reserve equivalent to n months operating income would be
returned to registrants in the form of a regularly-awarded lottery prize.

Running lotteries is, I believe, an activity that the State of
California reserves to itself. Do you not think the California
authorities might have something to say about ICANN procuring the
creation and operation of lotteries that they consider illegal? Do you
not think that were ICANN to seek to compel this registry to carry out
its "obligation" to run a lottery, they would look at ICANN as a joint
conspirator?

> I'm not sure what "real world" examples of this there would be -- where
> a registry puts new obligations on ICANN.  I think this is so rare as to
> be essentially not worth considering.

In that case you may wish to consult the IPC submission on this subject,
which argues that it should be an obligation upon ICANN to enforce every
provision of every contract.


> Of course, if an application did require ICANN to break the law, I would
> expect that application to be rejected or modified, rather than having
> that obligation placed into an agreement.  Indeed, if it were to ever
> get that far, a contractual provision that violated the law would be
> void as against public policy (at least under US law).

Wonderful! Now we're getting somewhere.

All I am saying is that this should apply, not only in respect of
statute law, but also in respect of ICANN's Articles and Bylaws (which
are also a form of law, and capable of having legally enforceable
consequences).

This is perfectly normal and expected. That's why you're having to argue
for additional text to disapply it, while those on my side of this
argument are satisfied with the default position at law.

>     > What¹s the principle - freedom of
>     > contract?
> 
>     No.
> 
>     The Registry's freedom of contract is not limited, subject to applicable
>     law. But ICANN's is freedom of contract is additionally limited by the
>     Bylaws.
> 
> 
> ​We are talking about a single contract here -- between a registry
> operator and ICANN.

No, we're not.

The Registry is free to contract with other counter-parties, as it
wishes, if they agree to contract with the Registry. The Registry's
"freedom of contract" does not imply a right to compel ICANN to contract
with it on the terms it offers, just as it does not imply a right to
contract with you or me.

ICANN ought to refuse to enter into contracts that aim at objectives
outside the scope of its Mission (or which are incompatible with other
elements of the Bylaws for that matter); the Bylaws ought to compel
ICANN to make such refusal.

Registries are not bound by the limits of ICANN's Mission, and are free
to make contractually enforceable promises to others that choose to
accept them.

-- 
            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