<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Finally, responding to Becky's questions:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span style="font-family:arial,sans-serif;font-size:12.8px">So I will restate the specific questions for the CCWG:</span><br style="font-family:arial,sans-serif;font-size:12.8px"><br style="font-family:arial,sans-serif;font-size:12.8px"><span style="font-family:arial,sans-serif;font-size:12.8px">1. Do you agree or disagree with the following statement: "To the extent</span><br style="font-family:arial,sans-serif;font-size:12.8px"><span style="font-family:arial,sans-serif;font-size:12.8px">that registry operators voluntarily assume obligations with respect to<br>registry operations as part of the application process, ICANN should have<br></span><span style="font-family:arial,sans-serif;font-size:12.8px">the authority to enforce those commitments.²</span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default"><font face="verdana, sans-serif"><br></font></div><div class="gmail_default"><font face="verdana, sans-serif">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.</font></div><div class="gmail_default"><font face="verdana, sans-serif"><br></font></div><div class="gmail_default"><font face="verdana, sans-serif">"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.<br></font><br style="font-family:arial,sans-serif;font-size:12.8px"><span style="font-family:arial,sans-serif;font-size:12.8px">2. Do you agree or disagree with the following statement: "ICANN shall not</span><br style="font-family:arial,sans-serif;font-size:12.8px"><span style="font-family:arial,sans-serif;font-size:12.8px">regulate services that use the Internet's unique identifiers, or the<br></span><span style="font-family:arial,sans-serif;font-size:12.8px">content that such services carry or provide.² - Wherever you land, please</span><br style="font-family:arial,sans-serif;font-size:12.8px"><span style="font-family:arial,sans-serif;font-size:12.8px">explain what you mean by ³regulate² and ³services."</span><br style="font-family:arial,sans-serif;font-size:12.8px"><br><font face="verdana, sans-serif">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.</font></div><div class="gmail_default"><font face="verdana, sans-serif"><br></font></div><div class="gmail_default"><font face="verdana, sans-serif">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.</font></div><div class="gmail_default"><br></div><div class="gmail_default"><font face="verdana, sans-serif">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.</font></div><div class="gmail_default"><font face="verdana, sans-serif"><br></font></div><div class="gmail_default"><br></div><div class="gmail_default"><font face="verdana, sans-serif">Greg</font></div><div class="gmail_default"><br></div><div class="gmail_default"><br style="font-family:arial,sans-serif;font-size:12.8px"><span style="font-family:arial,sans-serif;font-size:12.8px">I would be very interested in responses to these specific an limited</span><br style="font-family:arial,sans-serif;font-size:12.8px"><span style="font-family:arial,sans-serif;font-size:12.8px">questions.</span><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 11, 2015 at 12:52 AM, Dr Eberhard W Lisse <span dir="ltr"><<a href="mailto:el@lisse.na" target="_blank">el@lisse.na</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Many words, but still wrong.<br>
<br>
Any consensus is measured by the members, appointed by the chairing organizations.<br>
<br>
Commenters have, per se, nothing to do with it.<br>
<br>
Unless of course they are ALAC appointed members.<br>
<br>
el<br>
<br>
--<br>
Sent from Dr Lisse's iPad mini<br>
<div><div class="h5"><br>
> On 11 Nov 2015, at 02:55, Malcolm Hutty <<a href="mailto:malcolm@linx.net">malcolm@linx.net</a>> wrote:<br>
><br>
><br>
> Dear Becky,<br>
><br>
> According to our charter, the following definitions are used:<br>
> a) Full Consensus - a position where no minority disagrees; identified<br>
> by an absence of objection<br>
> b) Consensus – a position where a small minority disagrees, but most agree<br>
><br>
> See <a href="https://community.icann.org/display/acctcrosscomm/Charter" rel="noreferrer" target="_blank">https://community.icann.org/display/acctcrosscomm/Charter</a><br>
><br>
><br>
> I am writing to supply evidence that two of your consensus level<br>
> estimations are not consistent with these standards.<br>
><br>
> I am writing to disagree with your estimation of the level of consensus<br>
> on certain points.<br>
><br>
>> o To the extent that registry operators voluntarily assume obligations<br>
>> with respect to registry operations as part of the application process,<br>
>> ICANN should have the authority to enforce those commitments.<br>
>><br>
>> /NOTE: There is not “full consensus” on this position/.<br>
><br>
> To the extent that this principle as stated would override the principle<br>
> that ICANN should not seek to regulate the content of web sites or the<br>
> general business practices of domain registrants (parties who have no<br>
> privity of contract with ICANN), I believe there is widespread<br>
> disagreement with your proposal in evidence in the public comment record.<br>
><br>
> Please find attached 11 comment extracts from the first public comment<br>
> period. I have chosen these 11 comments as being examples that clearly<br>
> and unequivocally expresses opposition to your proposed principle, to<br>
> the extent stated above. These comments come from a broad range of<br>
> stakeholders, including a Congressional Resolution.<br>
><br>
> I therefore content that the correct assessment is that there is *no<br>
> consensus* in favour of this principle.<br>
><br>
>> *We do not appear to have consensus on the following concept*: /Without<br>
>> in any way limiting the foregoing absolute prohibition, ICANN shall not<br>
>> regulate services that use the Internet's unique identifiers, or the<br>
>> content that such services carry or provide./<br>
><br>
> The same attached comments express clear support for this concept, and<br>
> in many cases explicit endorsement of the wording.<br>
><br>
> The only criticism of it in the public comment was from the intellectual<br>
> property stakeholders spread across BC/IPC.<br>
><br>
> Since there is both broadly based support and the only objections to<br>
> this principle come from a narrow segment of the community, I contend<br>
> that the proper assessment is that this principle *has achieved<br>
> consensus, stopping short of full consensus*.<br>
><br>
>> 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.<br>
><br>
> Becky, I'm afraid the only person who keeps coming back to Specification<br>
> 1/Spec 4 as an adequate statement of the bounds of the Mission is you.<br>
> And whenever you do so, it is challenged.<br>
><br>
> I don't think you have any basis whatsoever for claiming that this group<br>
> as a whole has selected these documents as its view of the best or most<br>
> appropriate way to define or describe the parameters of the Mission, let<br>
> alone the best mechanism for recording those parameters.<br>
><br>
> I contend that the text in the first and second public comment rounds<br>
> has a much better claim to represent a consensus view of how to draw the<br>
> bounds of ICANN's Mission in this area. Unlike those demanding further<br>
> changes, I offer evidence in support of this claim, in the form of the<br>
> attached document.<br>
><br>
> It seems to me deeply regretable and contrary to our declared aims of<br>
> transparency and inclusion to disregard both the general tenor and<br>
> explicit recommendations of the public comment, and to allow vitally<br>
> important last minute changes to be pushed through at the behest of a<br>
> small group merely because that group has greater stamina for conducting<br>
> a war of attrition.<br>
><br>
> Removing the widely popular restriction on ICANN's Mission would<br>
> dishonour the public comment. For that reason, this group really ought<br>
> not to support your proposal. Public comment replies should matter.<br>
><br>
> There being no new proposal that has reached consensus and that still<br>
> honours the public comment response, the only proper course is to<br>
> proceed with the existing text. Those few that disagree may be invited<br>
> submit a minority statement, should they wish to do so.<br>
><br>
><br>
> Kind Regards,<br>
><br>
> Malcolm.<br>
><br>
> --<br>
> Malcolm Hutty | tel: <a href="tel:%2B44%2020%207645%203523" value="+442076453523">+44 20 7645 3523</a><br>
> Head of Public Affairs | Read the LINX Public Affairs blog<br>
> London Internet Exchange | <a href="http://publicaffairs.linx.net/" rel="noreferrer" target="_blank">http://publicaffairs.linx.net/</a><br>
><br>
> London Internet Exchange Ltd<br>
> Monument Place, 24 Monument Street, London EC3R 8AJ<br>
><br>
> Company Registered in England No. 3137929<br>
> Trinity Court, Trinity Street, Peterborough PE1 1DA<br>
><br>
><br>
</div></div>> <Mission comments extracts.docx><br>
> <Mission comments extracts.pdf><br>
<div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> Accountability-Cross-Community mailing list<br>
> <a href="mailto:Accountability-Cross-Community@icann.org">Accountability-Cross-Community@icann.org</a><br>
> <a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/accountability-cross-community</a><br>
_______________________________________________<br>
Accountability-Cross-Community mailing list<br>
<a href="mailto:Accountability-Cross-Community@icann.org">Accountability-Cross-Community@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/accountability-cross-community</a><br>
</div></div></blockquote></div><br></div>