[CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract

Malcolm Hutty malcolm at linx.net
Wed Nov 11 15:26:02 UTC 2015



On 11/11/2015 14:47, Burr, Becky wrote:
> Could I get you to expand on one point Robin, Paul and others?  To
> the extent ICANN obligates registrars to make registrants agree to
> submit to a UDRP, is that regulation of parties not in privity of
> contract with ICANN?  What about the requirement that registrants
> provide accurate WHOIS Information.  

Perhaps I can take that.

The proposal that we frame this as a prohibition on "regulation of
parties not in privity of contract with ICANN" is a proposal from BC and
USCIB. It is one form of wording that aims at the same basic intent as
the original wording.

For myself, I think this alternative wording is intended to resolve one
fear (that an excessively broad interpretation of "regulate" might
result in ICANN being unable to form contracts of any sort), but it
introduces problems of its own. If the BC's wording were used, I think
UDRP and WHOIS requirements would be in jeopardy. I wouldn't want to do
that, not do I see any public comment that suggests this is anybody's
aim, least of all BC. That's why, when we sought a compromise that would
address that concern, we did not adopt the BC wording, but instead added
the following:

"ICANN shall have the ability to negotiate, enter into and
enforce agreements with contracted parties in service of its Mission."

I think this is a good faith effort to accomodate the point that BC and
USCIB raised, without reneging on the basic attempt to prevent the
downstream content regulation, a principle that BC, USCIB have been
clear that they also support. In other words, if we keep the Second
Draft Report text and adopt the above sentence in addition, I believe we
can in good conscience say that we have accommodated BOTH those that
supported the original language AND the BC/USCIB input. Such
reconciliation is surely what we should be aiming at, is it not?

So the answer to your question is that if we go with the Second Draft
Report language (with or without the additional sentence), I don't think
there is any problem with continuing UDRP or WHOIS. If we adopted the BC
text as an alternative solution, I think that would make the UDRP ultra
vires (which is surely accidental on BC's part).

> What about the new gTLD
> applicant guidebook prohibition on Strings at the top level that
> advocate behavior that violateS globally accepted human rights
> standards?

> These examples are things that ICANN does right now. Are they ultra
> vires under the regulatory prohibition? If not, why not?


Again, we need to distinguish between the BC text and the Second Draft
Report text.

I think that BC text would create a conflict here too.

The Second Draft Report text (with or without the additional sentence
quoted above) would not conflict with those rules. The reason is that
the text does not restrain ICANN in its choices as to which top-level
domains to approve or decline to approve in any way.

The text only restricts ICANN from seeking to regulate the services
(such as web servers) that use the DNS. Declining to approve the
delegation of a controversial string could not credibly be said to be an
example of regulating the services (such as web servers) that use the
DNS. Any attempt to mount such a claim in an IRP challenge would be
doomed to failure. Indeed, assuming the IRP adopts procedures for the
swift dismissal of claims with no reasonable prospect of success, as we
recommend elsewhere in our report, such an ill-founded claim would be
dismissed rapidly.

That said, Alan Greenberg has said he doesn't consider this point to be
as unequivocally clear as I claim. Alan and I are entirely in agreement
that this clause should not restrain ICANN's unlimited discretion as to
which strings to approve as new gTLDs, but Alan thinks there is room for
confusion on whether our text successfully achieves that. I would be
happy to add a drafting note to our lawyers that the final text must not
bring this into question.

In conclusion, as long as we proceed with the text that has been
published, scrutinised, commented upon and widely suppored, we need have
no fear concerning the points you raise.

Your questions do, however, point up the dangers of unforeseen
consequences in making, at this late stage, substantial changes to the
text we have previously published.

Kind Regards,

Malcolm.


> Sent from my iPad
> 
>> On Nov 11, 2015, at 8:30 AM, Robin Gross <robin at ipjustice.org>
>> wrote:
>> 
>> I do not agree that there lacks consensus on including the text
>> which states ICANN won't regulate content.  There IS consensus on
>> that point, but not full consensus because a small minority
>> disagrees with that position (IPC).  Some in the BC don't even take
>> this extreme IPC position.
>> 
>> Many different parts of the community have commented that this is a
>> crucial component to our proposed accountability plan, so taking it
>> out at this stage, simply because the IPC won't relent is
>> unacceptable.  The other parts of the community have to accept that
>> we don't always get everything we want, and I find it difficult to
>> understand why the same standard doesn't apply to the IPC - why we
>> continue to go in circles until the IPC is satisfied.  These extra
>> bites at the apple must stop.  We need some strength and backbone
>> in our chairs and rapporteurs to not allow a small minority to
>> impose this on the rest of the community, simply by refusing to
>> relent until time runs out.
>> 
>> Deleting this point, which has been repeatedly stated as crucial
>> for such a wide segment of the community will create much more
>> trouble for the acceptance of our report than not allowing the IPC
>> to get everything it wants.
>> 
>> Robin
>> 
>>> On Nov 10, 2015, at 7:19 PM, Malcolm Hutty wrote:
>>> 
>>> 
>>> 
>>>> On 11/11/2015 02:10, Burr, Becky wrote: Malcolm et al:
>>>> 
>>>> I have to agree that the 11 comments appended by Malcolm
>>>> express strong support for the notion that ICANN should not use
>>>> its contractual authority to ³regulate services that use the
>>>> DNS or the regulation of content these services carry or
>>>> provide² and that ICANN should not attempt to establish 
>>>> obligations on non-contracted parties.² But the very commenters
>>>> cited (BC, USCIB, etc.)
>>> 
>>> Do you mean to imply that more than those two did?
>>> 
>>>> also request clarification regarding ICANN¹s authority to 
>>>> enforce its contracts.  What are we to make of this?
>>> 
>>> That's misleading. They didn't make a generalised, open-ended
>>> request for clarification that opens the door to you to construct
>>> an entirely new principle inconsistent with the main principle.
>>> They had a proposal of their own.
>>> 
>>> BC said:
>>> 
>>> BC strongly support the proposition that ICANN should not attempt
>>> to establish obligations on non-contracted parties. Paragraph 60
>>> should be clarified and we propose that it should read as
>>> follows: “ICANN shall not engage in or use its powers to attempt
>>> to establish contractual obligations on companies with which it
>>> is not in privity of contract and shall not attempt to establish
>>> contractual obligations on contracted parties that are not agreed
>>> by such parties.”
>>> 
>>> Similarly, USCIB said:
>>> 
>>> Indeed, ICANN’s entire multi-stakeholder structure is built on a 
>>> self-regulatory system implemented through contractual
>>> obligations and thus ICANN can only establish contractual
>>> obligations on parties with which it has privity through a
>>> negotiated and mutually agreeable contract/amendment with such
>>> parties. Therefore, para 60 should be clarified and we propose
>>> that it should read as follows: “ICANN shall not engage in or use
>>> its powers to attempt to establish contractual obligations on
>>> companies with which it is not in privity of contract and shall
>>> not attempt to establish contractual obligations on contracted 
>>> parties that are not agreed by such parties.”
>>> 
>>> 
>>> This new language is simply not consistent with the proposition
>>> that ICANN should have any ability to enter into contracts with
>>> Registries for the purpose of regulating (or controlling, or 
>>> any-of-a-number-of-other-verbs) the companies who register domain
>>> names, their business models or the content those companies carry
>>> on their web sites. Doing any of those things would entail
>>> "establishing contractual obligations on companies with which it
>>> [ICANN] is not in privity of contract", which is precisely what
>>> they say ICANN must not do.
>>> 
>>> 
>>>> With all due respect Malcolm, I will take a back seat to no one
>>>> as a consistent and ardent defender of ICANN¹s limited
>>>> mission.
>>> 
>>> Take care, Becky. You are starting to make it sound as though
>>> your own self-image as the defender of ICANN's limited mission is
>>> getting in the way of recognising other input with that same aim,
>>> but with which you personally disagree.
>>> 
>>>> So I will restate the specific questions for the CCWG:
>>>> 
>>>> 1. Do you agree or disagree with the following statement: "To
>>>> the extent that registry operators voluntarily assume
>>>> obligations with respect to registry operations as part of the
>>>> application process, ICANN should have the authority to enforce
>>>> those commitments.²
>>> 
>>> The expressed view of these 11 commenters (including, I note, the
>>> formal submission of the BC) clearly gives their answer to this
>>> question as "disagree", at least inasmuch as those obligations
>>> impose further obligations on third parties (registrants) that
>>> limit what content they may carry or provide on their web sites
>>> and suchlike services.
>>> 
>>> There is simply no fair reading of these 11 commenters'
>>> submissions that could answer this question as "agree", without
>>> first adding very substantial qualifications to the generality of
>>> your proposition.
>>> 
>>>> 2. Do you agree or disagree with the following statement:
>>>> "ICANN shall not regulate services that use the Internet's
>>>> unique identifiers, or the content that such services carry or
>>>> provide.²  - Wherever you land, please explain what you mean by
>>>> ³regulate² and ³services."
>>> 
>>> 9 of these 11 have said they agree, and accept the wording - so
>>> they don't accept your suggestion that the words "regulate" or
>>> "services" are unclear in the context used in the Draft Report.
>>> 
>>> 2 of these 11 have also said they agree, but propose alternate
>>> wording to achieve that; you may consider this wording, quoted
>>> above, as responsive to your question about defining "regulate"
>>> and "services".
>>> 
>>> 
>>>> I would be very interested in responses to these specific an
>>>> limited questions.
>>> 
>>> -- 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
>>> 
>>> 
>>> _______________________________________________ 
>>> Accountability-Cross-Community mailing list 
>>> Accountability-Cross-Community at icann.org 
>>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>

--
>>> 
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 Accountability-Cross-Community mailing list