<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Becky,</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Thanks again for your suggestion. I think it's a good attempt to "cut the Gordian knot" and avoid the issue of wrestling with a deeply flawed proposed bylaw and I would support it.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">It is unfortunate that some want to analyze this merely in "tribal" terms or in terms of "appeasement." This is a simplistic misdirection from the more universal issues and problems with the proposed Bylaw. It does expose quite neatly, however, that for some this Bylaw is not here primarily to try and "score points" in a discussion happening elsewhere in ICANN, one that will not be resolved one way or the other in these Bylaws or in the CCWG. Those who want it here for a particular purpose see it only for that purpose, and end up overlooking the fundamental infirmities, ambiguities and difficulties inherent in the proposed Bylaw, whether one looks at it as an instruction to our lawyers or as an attempt to draft an actual Bylaw.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">As Becky notes, while there was support for the Bylaw, there was also considerable concern about the effect it would have on contracts. Any solution has to take those issues into account.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">We have still not resolved the issue of what is meant by a "service," an ambiguous term that apparently may have a meaning specific to Telcoms professionals but not one that is broadly understood or tends to exclude other meanings in the context of a corporate Bylaw. I am confident that our lawyers (even though one is a Tech Transactions lawyer not unlike myself) will not grasp what Malcolm thinks this conveys. In any event, one of the rules of good legal drafting is to avoid jargon or terms of art specific to an industry, except in a document of such narrow application that it will be instantly obvious what the meaning is. In any event, many types of legal documents have "definitions" section, where terms are defined and ambiguities resolved.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">The new language proposed by Malcolm is somewhat enlightening (though clunky) but doesn't really solve the problem, because it is still modifying the term "services" where the real issue lies.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">We have not resolved what is meant by "regulation" and what is excluded from "regulation" even though it could reasonably be called regulation. It may seem self-evident to one steeped in ICANN that Consensus Policy is not regulation (or that a registry or a registrar is not a "service") but that is not otherwise clear from this Bylaw.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">As for "content" -- it's not clear what that covers either. Alan Greenberg has asked for a clarification (not satisfactorily dealt with) that "unique identifiers" are not "content" within the meaning of this Bylaw. Are PICs a form of "content regulation"? How about the UDRP (which is clearly permitted under Specification 1, even though it takes "use" (i.e., content) into account)? Or the URS and the PDDRP? </div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">The purpose is also far from clear from the language itself, although those that placed it here seem to know what they think they want it to cover, and hope to coax out of its opacity. (And I think different people or groups want different things out of the same language.) I'm still not sure of all the possibilities myself. If the idea of the "services" clause is that ICANN shouldn't have the power to "regulate" ISPs and IXPs, then it should say so -- but I"m not sure that's what it's about. </div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">It's also completely unclear what the linkage is between the last sentence and the second sentence. They sit next to each other in this particular Bylaw, so some linkage is intended, but what that linkage is remains largely obscure.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Now perhaps all this ambiguity and obscurity is a good thing, because the reasonable interpretations of this Bylaw will vary so wildly that we will spend years disputing its meaning and using it to support widely varying conclusions, like the murmurings of some Delphic oracle. In the end this will probably do little to advance the resolution of the concerns at which it is aimed, and may actually hinder such resolution.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Maybe we can still resolve the issues in Malcolm's redraft of the Bylaws to everyone's reasonable satisfaction. But we are working with poor materials, and the result will still be troublesome for that reason. Your revision has raised my hopes that we don't have to to do so.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">In retrospect, we probably would have been better off with something that did not look like a bylaw, but instead said in plain English, "We want a bylaw that accomplishes the following:" Of course, then we would have to deal directly with the issues, instead of quasi-lawyering our way through a series of unkempt phrases that will more likely bedevil us than serve us in the years ahead.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Speaking for myself, if the purpose of this is to avoid, in general terms, the imposition of unilateral restrictions on ISPs and IXPs, I am highly sympathetic to that, and I don't think it runs at cross-purposes to my concerns, except perhaps on the verges. Similarly, if the purpose is to stop ICANN from being used as a tool for the unilateral imposition of rules designed to stifle the expression of opinions or the expression of creators of content, and thereby create a less "open" Internet, I am highly sympathetic to that as well. A Bylaw that does both of those things, and only those things, should have broad support from all stakeholder groups, including the business and intellectual property communities. However, a Bylaw that cloaks itself in these things, but is intended to nullify portions of ICANN's existing contracts or to protect those who engage in illegal activity, including trafficking in stolen property -- I have no sympathy with that whatsoever. I think that is a highly improper and inappropriate use of the CCWG and it is certainly something that is not going to be viewed favorably in Congress or the NTIA -- nor should it be viewed favorably by anyone in the ICANN community, no matter what "tribe" you are affiliated with.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Greg</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 6, 2015 at 2:51 PM, Edward Morris <span dir="ltr"><<a href="mailto:egmorris1@toast.net" target="_blank">egmorris1@toast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Well put. I completely agree with Robin on this both in terms of substance and of procedure. We've already seen efforts to bring in content regulation through the back door, most recently in Dublin by some of our friends and colleagues. We need to make it plain, transparent and clear that content regulation is not part of ICANN's remit. The current language does so. The proposed change does not.</div><div><br></div><div>Best,</div><div><br></div><div>Ed</div><div><br></div><div><br><br>Sent from my iPhone</div><div><div class="h5"><div><br>On Nov 6, 2015, at 7:38 PM, Robin Gross <<a href="mailto:robin@ipjustice.org" target="_blank">robin@ipjustice.org</a>> wrote:<br><br></div><blockquote type="cite"><div>Unfortunately, this deletion would represent a big step backwards from consensus. There were quite a few public comments from a wide range of stakeholders that made note of the importance of the phrase in the mission to limit ICANN from regulating in this matter, so deleting it now would cause considerable disturbance to the consensus and go against public comment. I appreciate the pressure to appease the IPC, but this would be unfair to the many public commenters and other participants who have been relying on this critical language being included in the final text.<div><br></div><div>Thanks,</div><div>Robin<br><div><br></div><div><br><div><div>On Nov 6, 2015, at 9:30 AM, Burr, Becky wrote:</div><br><blockquote type="cite">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>
<div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
All: At the risk of causing a riot, I confess that am getting increasingly concerned that we are confusing ourselves (and possibly the bylaws) by trying to include and explain the prohibition on regulation of services that use the Internet’s unique identifiers
or the content that such services carry or provide. Perhaps we would be better off relying on a clear Mission statement and enhanced accountability mechanisms to prevent mission creep? I could certainly make the argument, based on the proposed mission statement,
that ICANN has no authority to regulate ISPs, or to use its authority over registries and registrars to do so indirectly. (Please note, ICANN’s Bylaws currently authorize ICANN to enter into contracts. See Article XV, Section 1). </div>
<div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
<br>
</div>
<div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
Should we discuss this approach? The report language on ICANN’s Mission Statement, reflecting the recent changes to address IAB/IETF concerns, would then read:</div>
<div>
<div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">The Mission of The Internet Corporation for Assigned Names and Numbers ("ICANN") is to ensure the stable and secure operation of the Internet's unique identifier systems in the ways described below. Specifically, ICANN:</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">1. Coordinates the allocation and assignment of names in the root zone of the Domain Name System ("DNS"). In this role, ICANN’s Mission is to coordinate the development and implementation of policies:</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">•<span style="white-space:pre-wrap">
</span>For which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS; and</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">•<span style="white-space:pre-wrap">
</span>That are developed through a bottom-up, consensus-based multi- stakeholder process and designed to ensure the stable and secure operation of the Internet’s unique names systems.</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">2. Coordinates the operation and evolution of the DNS root name server system. In this role, ICANN’s Mission is to [to be provided by root server operators].</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">3. Coordinates the allocation and assignment at the top-most</font></div>
<div><font face="Calibri,sans-serif">level of Internet Protocol ("IP") and Autonomous System ("AS") numbers. ICANN’s Mission is described in the ASO MoU between ICANN and RIRs.</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">4. Collaborates with other bodies as appropriate to publish core registries needed for the functioning of the Internet. In this role, with respect to protocol ports and parameters, ICANN's Mission is to provide registration
services and open access for registries in the public domain requested by Internet protocol development organizations, such as the Internet Engineering Task Force.</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">ICANN shall act strictly in accordance with, and only as reasonably appropriate to achieve its Mission.
<strike><font color="#ff0000">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. ICANN shall have the ability to enforce
agreements with contracted parties, subject to established means of community input on those agreements and reasonable checks and balances on its ability to impose obligations exceeding ICANN’s Mission on registries and registrars.</font></strike> </font></div>
</div>
<div style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">
<br>
</div>
<p class="MsoNormal" style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px;margin-top:12pt">
</p><p class="MsoNormal" style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px;margin-top:12pt">
<b><span style="font-size:9pt;line-height:115%">J. Beckwith Burr</span></b><b><span style="font-size:10.0pt;line-height:115%;color:#262626">
</span></b><b><span style="font-size:9.0pt;line-height:115%;color:#3366ff"><br>
</span></b><b><span style="font-size:9.0pt;line-height:115%;color:#008656">Neustar, Inc.</span></b><b><span style="font-size:9.0pt;line-height:115%;color:#068658">
</span></b><span style="font-size:9.0pt;line-height:115%;color:#7d7d7d">/</span><b><span style="font-size:9.0pt;line-height:115%;color:#068658">
</span></b><span style="font-size:9.0pt;line-height:115%;color:#7d7d7d">Deputy General Counsel & Chief Privacy Officer<br>
1775 Pennsylvania Avenue NW, Washington D.C. 20006</span><span style="font-size:9.0pt;line-height:115%;color:gray"><br>
</span><b><span style="font-size:9.0pt;line-height:115%;color:#008656">Office:</span></b><b><span style="font-size:9.0pt;line-height:115%;color:#7d7d7d">
</span></b><span style="font-size:9.0pt;line-height:115%;color:#7d7d7d"><a href="tel:%2B1.202.533.2932" value="+12025332932" target="_blank">+1.202.533.2932</a>
</span><b><span style="font-size:9.0pt;line-height:115%;color:#008656">Mobile:</span></b><b><span style="font-size:9.0pt;line-height:115%;color:#7d7d7d">
</span></b><span style="font-size:9.0pt;line-height:115%;color:#7d7d7d"><a href="tel:%2B1.202.352.6367" value="+12023526367" target="_blank">+1.202.352.6367</a>
<strong><span style="font-family:Arial">/</span></strong></span><span style="font-size:9.0pt;line-height:115%;color:#068658">
</span><a href="http://www.neustar.biz/" target="_blank"><b><span style="font-size:9.0pt;line-height:115%;color:#008656">neustar.biz</span></b></a><span style="font-size:9.0pt;line-height:115%;color:gray"><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
_______________________________________________<br>Accountability-Cross-Community mailing list<br><a href="mailto:Accountability-Cross-Community@icann.org" target="_blank">Accountability-Cross-Community@icann.org</a><br><a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" target="_blank">https://mm.icann.org/mailman/listinfo/accountability-cross-community</a><br></blockquote></div><br></div></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Accountability-Cross-Community mailing list</span><br><span><a href="mailto:Accountability-Cross-Community@icann.org" target="_blank">Accountability-Cross-Community@icann.org</a></span><br><span><a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" target="_blank">https://mm.icann.org/mailman/listinfo/accountability-cross-community</a></span><br></div></blockquote></div></div></div><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>
<br></blockquote></div><br></div>