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

Wed Nov 11 08:18:36 UTC 2015

Finally, responding to Becky's questions:

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

I agree with this statement, but I disagree with any implication that these
are the only obligations that ICANN can enforce.  In any contract between
two parties (including the RA and the RAA), each party is bound to comply
with each and every obligation in the contract pertinent to that party; if
a party fails to comply, the other party can and should take steps to
ensure that the party complies; if the non-compliance rises to the level of
breach, the non-breaching party has every right to enforce the provisions
of the agreement that come into play at that time.  So, to make a long
story short, ICANN -- like every other party to every other contract --
should have the right to "enforce" every obligation of its
counter-parties.  And those counter-parties have the right to do the same
to ICANN.

Any bylaw that implies that ICANN's contracts are contracts of adhesion (in
whole or in part) and thus do not need to be complied with (in whole or in
part) due to that bylaw or are nullified (in whole or in part) by that
bylaw is a very unique and dangerous idea that really has no place in a
bylaw.  And I would say that under any circumstances.

"Contracts of adhesion" are a narrow concept with very specific criteria
that may allow a party to get out from under the agreement.  There's a body
of law around this concept, including the type and level of proof needed.
Using a bylaw to rewrite this law just for ICANN is very troublesome.

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

With the right definition of "regulate" and "services" I could agree with
this statement.  First, I would define regulation as the unilateral
imposition of rules (typically, rules of conduct) by a regulatory body.  As
such, entering into, complying with and enforcing contracts is mutually
exclusive from "regulation." This includes the RA, the RAA and any end-user
or registrant agreements that include provisions specified in ICANN's
agreements.  That does not mean that ICANN can do anything it wants in its
agreements, only that what occurs in those agreements is not "regulation"
(or any synonym for regulation).  I would also emphasize that any consensus
policy, as defined in the Consensus Policy Specification, should not be
considered "regulation" either.

As for "services" my concern is a more neutral one of clarity; "services"
can have a number of meanings.  Whatever we draft will need to be
interpreted by our counsel (who are not telecom lawyers) and by the larger
community, including non-native English speakers, so our meaning needs to
be clear.  If "services" is limited to the "Internet services" that use the
DNS offered by an "Internet Service Provider," then I am likely okay;
however, we need a concrete list, even if it is exemplary rather than
exhaustive, so that the meaning is beyond doubt.  If we mean every entity
that provides any kind of service and does so through or using the Internet
and a domain name or IP address in some fashion, that's likely a problem --
this is simply too broad and off-topic for us to deal with.

If there's any intent or effect that this language will be used to waive,
nullify or make unenforceable any provision of any current ICANN contract,
that should be made clear now.  As a matter of fact, I would suggest that
we should have a statement to the effect that "This Bylaw may not be used
to challenge, nullify or make unenforceable any provision in any contract
with ICANN in effect as of the adoption of this Bylaw." That would solve a
lot of problems and make it clear that this Bylaw is not just a short-term
ploy to attempt to reshape ICANN's current contracts.

Greg

I would be very interested in responses to these specific an limited
questions.

On Wed, Nov 11, 2015 at 12:52 AM, Dr Eberhard W Lisse <el at lisse.na> wrote:

> Many words, but still wrong.
>
> Any consensus is measured by the members, appointed by the chairing
> organizations.
>
> Commenters have, per se, nothing to do with it.
>
> Unless of course they are ALAC appointed members.
>
> el
>
> --
> Sent from Dr Lisse's iPad mini
>
> > On 11 Nov 2015, at 02:55, Malcolm Hutty <malcolm at linx.net> wrote:
> >
> >
> > Dear Becky,
> >
> > According to our charter, the following definitions are used:
> > a) Full Consensus - a position where no minority disagrees; identified
> > by an absence of objection
> > b) Consensus – a position where a small minority disagrees, but most
> agree
> >
> > See https://community.icann.org/display/acctcrosscomm/Charter
> >
> >
> > I am writing to supply evidence that two of your consensus level
> > estimations are not consistent with these standards.
> >
> > I am writing to disagree with your estimation of the level of consensus
> > on certain points.
> >
> >> o   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.
> >>
> >>  /NOTE:  There is not “full consensus” on this position/.
> >
> > To the extent that this principle as stated would override the principle
> > that ICANN should not seek to regulate the content of web sites or the
> > general business practices of domain registrants (parties who have no
> > privity of contract with ICANN), I believe there is widespread
> > disagreement with your proposal in evidence in the public comment record.
> >
> > Please find attached 11 comment extracts from the first public comment
> > period. I have chosen these 11 comments as being examples that clearly
> > and unequivocally expresses opposition to your proposed principle, to
> > the extent stated above. These comments come from a broad range of
> > stakeholders, including a Congressional Resolution.
> >
> > I therefore content that the correct assessment is that there is *no
> > consensus* in favour of this principle.
> >
> >> *We do not appear to have consensus on the following concept*:  /Without
> >> in any way limiting the foregoing absolute prohibition, ICANN shall not
> >> regulate services that use the Internet's unique identifiers, or the
> >> content that such services carry or provide./
> >
> > The same attached comments express clear support for this concept, and
> > in many cases explicit endorsement of the wording.
> >
> > The only criticism of it in the public comment was from the intellectual
> > property stakeholders spread across BC/IPC.
> >
> > Since there is both broadly based support and the only objections to
> > this principle come from a narrow segment of the community, I contend
> > that the proper assessment is that this principle *has achieved
> > consensus, stopping short of full consensus*.
> >
> >> Coordinating development, implementation, and enforcement of Consensus
> Policy, as defined by Specification 1 of the New gTLD Registry Agreement
> and Specification 4 of the 2013 Registrar Accreditation Agreement, is
> within ICANN’s Mission.
> >
> > Becky, I'm afraid the only person who keeps coming back to Specification
> > 1/Spec 4 as an adequate statement of the bounds of the Mission is you.
> > And whenever you do so, it is challenged.
> >
> > I don't think you have any basis whatsoever for claiming that this group
> > as a whole has selected these documents as its view of the best or most
> > appropriate way to define or describe the parameters of the Mission, let
> > alone the best mechanism for recording those parameters.
> >
> > I contend that the text in the first and second public comment rounds
> > has a much better claim to represent a consensus view of how to draw the
> > bounds of ICANN's Mission in this area. Unlike those demanding further
> > changes, I offer evidence in support of this claim, in the form of the
> > attached document.
> >
> > It seems to me deeply regretable and contrary to our declared aims of
> > transparency and inclusion to disregard both the general tenor and
> > explicit recommendations of the public comment, and to allow vitally
> > important last minute changes to be pushed through at the behest of a
> > small group merely because that group has greater stamina for conducting
> > a war of attrition.
> >
> > Removing the widely popular restriction on ICANN's Mission would
> > dishonour the public comment. For that reason, this group really ought
> > not to support your proposal. Public comment replies should matter.
> >
> > There being no new proposal that has reached consensus and that still
> > honours the public comment response, the only proper course is to
> > proceed with the existing text. Those few that disagree may be invited
> > submit a minority statement, should they wish to do so.
> >
> >
> > 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
> >       Monument Place, 24 Monument Street, London EC3R 8AJ
> >
> >         Company Registered in England No. 3137929
> >       Trinity Court, Trinity Street, Peterborough PE1 1DA
> >
> >
> > <Mission comments extracts.docx>
> > <Mission comments extracts.pdf>
> > _______________________________________________
> > Accountability-Cross-Community mailing list
> > Accountability-Cross-Community at icann.org
> > https://mm.icann.org/mailman/listinfo/accountability-cross-community
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151111/c5924a7e/attachment.html>