<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">I have now read John Jeffrey's briefing note and Andrew Sullivan's response.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I share the concerns raised in the briefing note. I have a number of disagreements with Andrew's response, which I've inserted in-line below.</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 class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 17, 2016 at 10:20 AM, Andrew Sullivan <span dir="ltr"><<a href="mailto:ajs@anvilwalrusden.com" target="_blank">ajs@anvilwalrusden.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi John,<br>
<br>
Thanks for this. It's very helpful. I have a couple remarks in<br>
response. Sorry this is long; but, as the saying goes, I didn't have<br>
time to write a short note.<br>
<br>
To begin, I believe we have three interlocking goals in respect of<br>
this Mission text. I'll number them here for later reference, but in<br>
my opinion they're all of equal priority: (1) To ensure that ICANN's<br>
quite correct role in co-ordinating some kinds of actions with respect<br>
to the DNS remains permitted and understood to be legitimate. (2) To<br>
ensure that the Mission text cannot be used by those who would like to<br>
use ICANN to impose rules on the Internet generally. (3) To respect<br>
the consensus of the community as embodied in the existing, approved<br>
CCWG document.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">I believe there's a fourth goal regarding the Mission text, which is a corollary of Andrew's second goal: To ensure that the Mission text cannot be used to prevent ICANN from doing things that it properly can do (i.e., the revised Mission statement should not be overly restrictive, either intentionally or unintentionally). Also, while I agree with goal (3), "respect" does not mean "follow slavishly." Where an aspect of the document appears to raise issues, those issues need to be resolved, regardless of where we are in the process. While we did discuss this relatively recently in the CCWG, I've been thinking about the result we came to (which I supported at the time), and I now think the result (leaving the addition of "in the root zone" intact) was incorrect. </div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I'm glad your memo emphasises the conceptual nature of the CCWG<br>
report. I think that means two things. It means that the legal teams<br>
working on the bylaw text do not need to cleave to the words in the<br>
report. But of course, it also means that the legal teams also need<br>
to stick to the concepts that are in the report, in order to meet goal<br>
3. I hope we can all agree that the restriction of ICANN's scope to<br>
the root zone is an important conceptual point in the CCWG report, and<br>
can't simply be set aside as part of the drafting exercise. If we are<br>
not in agreement about that, perhaps we should concentrate on that<br>
basic issue on the call today -- since until we agree about what<br>
concepts are to be implemented in the bylaws, the drafting effort will<br>
only yield frustration.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">I do not agree</div> <font face="verdana, sans-serif">that the restriction of ICANN's scope to<div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"> </div></font><span style="font-family:verdana,sans-serif">the root zone is an important conceptual point in the CCWG report<div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">. At best it is an extrapolation from certain conceptual points in the CCWG report. While there are various restrictions we have put in the revised Bylaws, they do not add up to a restriction to the root zone. Rather, a restriction to the root zone is fundamentally at odds with ICANN's mission and scope in a number of ways (as outlined in the briefing note). I think the insertion of "in the root zone" may be consistent with the agenda of some participants, but I don't think it is consistent with the results of our efforts as a CCWG.</div></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Assuming that we are in agreement, then I have some responses to the<br>
issues outlined in the memo. </blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">As noted above, I reject that assumption. I think it's fair to say that the ICANN participants do too.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It seems to me that removing the term<br>
"root zone" would not be consistent with the concepts in the CCWG<br>
report. </blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">As noted above, I disagree and have made the opposite statement.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Moreover, I do not understand why it would need special<br>
definition: if you know what a "DNS" is, then you know what a "root<br>
zone" is, because a root zone is part of the very definition of the<br>
technnology. This technology is defined in a large number of RFCs,<br>
and of course the IETF is in a position to continue to change that<br>
definition. But if need be, I suppose, the Mission could refer to<br>
those RFCs and acknowledge that the meaning could change in the<br>
future.<br>
<br>
You note a worry "that the activities of ICANN at a level other than<br>
the 'root zone' would be subject to interpretation by an IRP panel as<br>
to whether it is within ICANN’s mission." I think that being subject<br>
to such interpretation is in fact precisely the point of the<br>
restriction, </blockquote><div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I share the concern in the quote. If "in the root zone" is not removed, there is a danger that it would be interpreted to bar ICANN from <u>all</u> activities at the second level, including those listed in the briefing note. That would be a massive mistake and a perfect example of the "doctrine of unintended consequences." (Putting aside the thought that, for some, this would be an intended (but unrevealed) consequence.) Frankly, I am concerned that there may be some "Easter Eggs"/"Trojan Horses" hidden in the Bylaws revisions, and this seems to fit the category. I don't think there was ever an intention to subject any and all "activities of ICANN at a level other than the 'root zone'" to a blanket prohibition.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">and this is in service of goal 2: the community does not<br>
want ICANN's authority to extend throughout the DNS. </blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">To the extent I buy into the concept of goal 2 (and I believe it is a double-edged sword -- the Mission should not be under-restrictive or over-restrictive), this is a restatement of goal 2 which drastically changes its meaning. It's one thing to say that we don't want ICANN "to impose rules on the Internet generally" and quite another thing to say that we don't want ICANN's "authority to extend throughout the DNS." "Imposing rules" is not the same thing as having "authority" and "the Internet generally" is not "the DNS." As such, while I can probably agree with the first statement of goal 2 (with my corollary concern about being overly restrictive), I can't agree with the restatement, which I find overly restrictive on its face and not reflective of what the community wants.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">In any event, we are not talking about "the Internet generally" or "the DNS." We are talking about authority at the second level. There's no need to restrict ICANN's authority to the root zone in order to prohibit ICANN from imposing rules on the Internet generally. This is totally over-restrictive. It's like locking your dog in a box in your bedroom closet, to prevent him from going outside.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><span style="font-family:arial,sans-serif"> </span><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I don't believe<div class="gmail_default" style="font-family:verdana,sans-serif;display:inline"> </div>ICANN wants such authority, either. </blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">If we define the level of authority correctly, we'll get somewhere. It's clear that ICANN see "in the root zone" as cutting ICANN off from legitimate actions, and I agree. If "such authority" was "imposing rules on the Internet generally," they would clearly agree that they don't want all that authority. Your restatement ("authority ... throughout the DNS") might get a different response, and the proposed language (essentially authority only "in the root zone") is clearly problematic.</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">(Incidentally, I don't see what<br>
the relevance of the existing ICANN byalws is here: the point of this<br>
effort is to clarify the Mission, and if the bylaws were already right<br>
there wouldn't be anything to do.)<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">There are many points to this effort, and many parts of the Mission that are already right. We can't assume, in Reign of Terror fashion, that the entire statement of the Mission in Bylaws is wrong. We have plenty to do to change the Bylaws, whether or not we make this particular change, so the idea that "there wouldn't be anything to do" justifies making this particular change doesn't hold water.</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
The examples you use of things that ICANN does beyond the root zone<br>
are, I suggest, policy activities that could equally flow from ICANN's<br>
authority over the root zone. The GNSO policies relating to<br>
registrations, for instance, are all policies that govern how certain<br>
registries will operate. </blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">If we are talking about second-level registrations (which I think we are), I disagree with this statement. I don't see how one can characterize all policies relating to registrations as registry policies.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The basis for that governance is ICANN's<br>
willingness to delegate the relevant parts of the namespace to the<br>
operator of this or that registry. Indeed, this distinction is<br>
exactly why there is a policy difference between gTLDs (contracted<br>
registries) and ccTLDs (who are not as a rule contracted parties).<br>
<br>
The examples of constraints on registrars could be understood as<br>
constraints that arise due to accreditation. ICANN can quite<br>
naturally extract any requirements it likes as part of its<br>
accreditation process. </blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">I think this is fundamentally untrue and at odds with so much of our work. ICANN can only extract requirements from registrars that are within its Mission. If we say that "ICANN can ... extract any requirements it likes" we've nullified a huge amount of work. Furthermore, this is completely non-obvious from everything else we've ever said. As such, if this is our philosophy, we'd better put that statement into the Bylaws (and I don't think we want to).</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">And it can extract a promise from registries<br>
under contract that such registries will only permit registration<br>
through accredited registrars. </blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">This is not "in the root zone," so I don't see how this would be allowed if this language stayed in the Bylaws.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Again, none of these policies extend<br>
to zones where ICANN does not have a direct contractual relationship<br>
to the registry operator: they don't automatically apply in ccTLDs and<br>
they also don't apply in <a href="http://anvilwalrusden.com" rel="noreferrer" target="_blank">anvilwalrusden.com</a> (which I operate).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">The contractual relationship cannot be used to explain the extent of ICANN's authority. Parochially, I wish it did. If we want to say that ICANN can contract for anything it wants as long as some attenuated relationship to the root zone can be found, there would be some happy stakeholders in my community. But I don't think that's where we ended up. The power to contract is bounded by ICANN's mission. For this reason, it's critically important that we do not put overly restrictive language in the Mission (just as it's important not to put overly permissive language in the Mission). I believe that "in the root zone" makes the Mission overly restrictive and could lead to restrictions and IRP findings far beyond what the community imagined.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Now, if you believe that somewhere ICANN needs explicit permission to<br>
impose these kinds of policy rules on those with whom it has direct<br>
contractual relationships, I think that would be entirely consistent<br>
with what the CCWG had already concluded. </blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">Permission does not need to be "somewhere," it needs to be embodied in the Mission. If the Mission is overly restrictive, there's no "permission" that can be granted to make up for this problem.</div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I thought that the<br>
inclusion of the "picket fence" language gave you that; but if not,<br>
then that seems an obvious addition.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;display:inline">The "in the root zone" language seems inconsistent with the "picket fence." In real life, picket fences can be destroyed by roots that run amok. This seems to be a virtual example of the same thing.</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I hope this is useful for framing discussion on the call today.<br>
<br></blockquote><div><div class="gmail_default" style="font-family:verdana,sans-serif">I hope my responses have been useful as well.</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><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Best regards,<br>
<br>
A<br>
<span class=""><br>
On Sat, Apr 16, 2016 at 09:24:09PM -0700, John Jeffrey wrote:<br>
> BCG Members — In preparation for the discussion of the Bylaws Coordination Group to be held at 21.00 UTC 17 April, please find attached a legal briefing note reflecting some of the discussion among ICANN counsel and the ICANN Board members on the topic of the bylaws mission language.<br>
><br>
<br>
<br>
><br>
><br>
</span>> best,<br>
> John Jeffrey<br>
> General Counsel & Secretary, ICANN<br>
<div class=""><div class="h5">><br>
><br>
> > On Apr 16, 2016, at 9:11 AM, Mathieu Weill <<a href="mailto:mathieu.weill@afnic.fr">mathieu.weill@afnic.fr</a>> wrote:<br>
> ><br>
> > Like Andrew I would appreciate some more inputs before the meeting (which I am unsure to attend at this point).<br>
> ><br>
> > Best<br>
> ><br>
> > Mathieu Weill<br>
> > ---------------<br>
> > Depuis mon mobile, désolé pour le style<br>
> ><br>
> >> Le 16 avr. 2016 à 15:56, Andrew Sullivan <<a href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a>> a écrit :<br>
> >><br>
> >> It would still be very helpful to have something to read to explain<br>
> >> what exactly has changed here. The CCWG has been asked about changing<br>
> >> this, and as far as I could tell there was not agreement that removing<br>
> >> the restriction is consistent with the CCWG consensus document. Is<br>
> >> there some new argument about how the removal would be so consistent?<br>
> >> Because if not, I don't really see how the removal can happen without<br>
> >> re-opening the community-approved proposal. Surely that'd be a bad thing.<br>
> >><br>
> >> Best regards,<br>
> >><br>
> >> A<br>
> >><br>
> >>> On Sat, Apr 16, 2016 at 01:46:23PM +0000, Grace Abuhamad wrote:<br>
> >>> Thank you all for your quick responses. We will do Sunday at 21:00 UTC. You will receive an invite shortly either from Brenda or me.<br>
> >>><br>
> >>><br>
> >>> Sent from my mobile device<br>
> >>><br>
> >>> On Apr 16, 2016, at 07:58, Rinalia Abdul Rahim <<a href="mailto:rinalia.abdulrahim@gmail.com">rinalia.abdulrahim@gmail.com</a><mailto:<a href="mailto:rinalia.abdulrahim@gmail.com">rinalia.abdulrahim@gmail.com</a>>> wrote:<br>
> >>><br>
> >>> Grace, not just hard for those in Europe, but also in Asia. Nevertheless, I can make the time slots.<br>
> >>><br>
> >>> Rinalia<br>
> >>><br>
> >>> On Saturday, 16 April 2016, Grace Abuhamad <<a href="mailto:grace.abuhamad@icann.org">grace.abuhamad@icann.org</a><mailto:<a href="mailto:grace.abuhamad@icann.org">grace.abuhamad@icann.org</a>>> wrote:<br>
> >>> Dear all,<br>
> >>><br>
> >>> We would like to schedule a Bylaws Coordination Group call to discuss language around the Root Zone. This 1h call would preferably take place today or tomorrow.<br>
> >>><br>
> >>> Based on the legal teams' availability, we have suggested three times below that are still within waking hours in other global time zones. Please respond to me with your preference, and we will get the invite and call details circulated as soon as possible.<br>
> >>><br>
> >>> Option 1: Saturday 16 April at 21:00 UTC<br>
> >>><br>
> >>> Option 2: Sunday 17 April at 20:00 UTC<br>
> >>><br>
> >>> Option 3: Sunday 17 April at 21:00 UTC<br>
> >>><br>
> >>> We acknowledge that these times are in small windows and late for our European colleagues, but we hope that these times can be accommodated.<br>
> >>><br>
> >>> Thank you,<br>
> >>> Grace<br>
> >>> _______________________________________________<br>
> >>> bylaws-coord mailing list<br>
> >>> <a href="mailto:bylaws-coord@icann.org">bylaws-coord@icann.org</a><javascript:;><br>
> >>> <a href="https://mm.icann.org/mailman/listinfo/bylaws-coord" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/bylaws-coord</a><br>
> >><br>
> >>> _______________________________________________<br>
> >>> bylaws-coord mailing list<br>
> >>> <a href="mailto:bylaws-coord@icann.org">bylaws-coord@icann.org</a><br>
> >>> <a href="https://mm.icann.org/mailman/listinfo/bylaws-coord" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/bylaws-coord</a><br>
> >><br>
> >><br>
> >> --<br>
> >> Andrew Sullivan<br>
> >> <a href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a><br>
> >> _______________________________________________<br>
> >> bylaws-coord mailing list<br>
> >> <a href="mailto:bylaws-coord@icann.org">bylaws-coord@icann.org</a><br>
> >> <a href="https://mm.icann.org/mailman/listinfo/bylaws-coord" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/bylaws-coord</a><br>
> > _______________________________________________<br>
> > bylaws-coord mailing list<br>
> > <a href="mailto:bylaws-coord@icann.org">bylaws-coord@icann.org</a><br>
> > <a href="https://mm.icann.org/mailman/listinfo/bylaws-coord" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/bylaws-coord</a><br>
><br>
<br>
<br>
--<br>
Andrew Sullivan<br>
<a href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a><br>
_______________________________________________<br>
bylaws-coord mailing list<br>
<a href="mailto:bylaws-coord@icann.org">bylaws-coord@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/bylaws-coord" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/bylaws-coord</a><br>
</div></div></blockquote></div><br></div></div>