[bylaws-coord] Group call today or tomorrow

Sun Apr 17 20:18:31 UTC 2016

I have now read John Jeffrey's briefing note and Andrew Sullivan's response.

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.

Greg

On Sun, Apr 17, 2016 at 10:20 AM, Andrew Sullivan <ajs at anvilwalrusden.com>
wrote:

> Hi John,
>
> Thanks for this.  It's very helpful.  I have a couple remarks in
> response.  Sorry this is long; but, as the saying goes, I didn't have
> time to write a short note.
>
> To begin, I believe we have three interlocking goals in respect of
> this Mission text.  I'll number them here for later reference, but in
> my opinion they're all of equal priority: (1) To ensure that ICANN's
> quite correct role in co-ordinating some kinds of actions with respect
> to the DNS remains permitted and understood to be legitimate.  (2) To
> ensure that the Mission text cannot be used by those who would like to
> use ICANN to impose rules on the Internet generally.  (3) To respect
> the consensus of the community as embodied in the existing, approved
> CCWG document.
>

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. 

>
> I'm glad your memo emphasises the conceptual nature of the CCWG
> report.  I think that means two things.  It means that the legal teams
> working on the bylaw text do not need to cleave to the words in the
> report.  But of course, it also means that the legal teams also need
> to stick to the concepts that are in the report, in order to meet goal
> 3.  I hope we can all agree that the restriction of ICANN's scope to
> the root zone is an important conceptual point in the CCWG report, and
> can't simply be set aside as part of the drafting exercise.  If we are
> not in agreement about that, perhaps we should concentrate on that
> basic issue on the call today -- since until we agree about what
> concepts are to be implemented in the bylaws, the drafting effort will
> only yield frustration.
>

I do not agree
 that the restriction of ICANN's scope to

the root zone is an important conceptual point in the CCWG report
.  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.

>
> Assuming that we are in agreement, then I have some responses to the
> issues outlined in the memo.

As noted above, I reject that assumption.  I think it's fair to say that
the ICANN participants do too.

> It seems to me that removing the term
> "root zone" would not be consistent with the concepts in the CCWG
> report.

As noted above, I disagree and have made the opposite statement.

> Moreover, I do not understand why it would need special
> definition: if you know what a "DNS" is, then you know what a "root
> zone" is, because a root zone is part of the very definition of the
> technnology.  This technology is defined in a large number of RFCs,
> and of course the IETF is in a position to continue to change that
> definition.  But if need be, I suppose, the Mission could refer to
> those RFCs and acknowledge that the meaning could change in the
> future.
>
> You note a worry "that the activities of ICANN at a level other than
> the 'root zone' would be subject to interpretation by an IRP panel as
> to whether it is within ICANN’s mission."  I think that being subject
> to such interpretation is in fact precisely the point of the
> restriction,

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 *all*
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.

> and this is in service of goal 2: the community does not
> want ICANN's authority to extend throughout the DNS.

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.

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.

> I don't believe
> 
> ICANN wants such authority, either.

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.

> (Incidentally, I don't see what
> the relevance of the existing ICANN byalws is here: the point of this
> effort is to clarify the Mission, and if the bylaws were already right
> there wouldn't be anything to do.)
>

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.

>
> The examples you use of things that ICANN does beyond the root zone
> are, I suggest, policy activities that could equally flow from ICANN's
> authority over the root zone.  The GNSO policies relating to
> registrations, for instance, are all policies that govern how certain
> registries will operate.

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.

> The basis for that governance is ICANN's
> willingness to delegate the relevant parts of the namespace to the
> operator of this or that registry.  Indeed, this distinction is
> exactly why there is a policy difference between gTLDs (contracted
> registries) and ccTLDs (who are not as a rule contracted parties).
>
> The examples of constraints on registrars could be understood as
> constraints that arise due to accreditation.  ICANN can quite
> naturally extract any requirements it likes as part of its
> accreditation process.

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

> And it can extract a promise from registries
> under contract that such registries will only permit registration
> through accredited registrars.

This is not "in the root zone," so I don't see how this would be allowed
if this language stayed in the Bylaws.

> Again, none of these policies extend
> to zones where ICANN does not have a direct contractual relationship
> to the registry operator: they don't automatically apply in ccTLDs and
> they also don't apply in anvilwalrusden.com (which I operate).
>

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.

>
> Now, if you believe that somewhere ICANN needs explicit permission to
> impose these kinds of policy rules on those with whom it has direct
> contractual relationships, I think that would be entirely consistent
> with what the CCWG had already concluded.

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.

> I thought that the
> inclusion of the "picket fence" language gave you that; but if not,
> then that seems an obvious addition.
>

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.

>
> I hope this is useful for framing discussion on the call today.
>
> I hope my responses have been useful as well.

Greg

> Best regards,
>
> A
>
> On Sat, Apr 16, 2016 at 09:24:09PM -0700, John Jeffrey wrote:
> > 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.
> >
>
>
> >
> >
> > best,
> > John Jeffrey
> > General Counsel & Secretary, ICANN
> >
> >
> > > On Apr 16, 2016, at 9:11 AM, Mathieu Weill <mathieu.weill at afnic.fr>
> wrote:
> > >
> > > Like Andrew I would appreciate some more inputs before the meeting
> (which I am unsure to attend at this point).
> > >
> > > Best
> > >
> > > Mathieu Weill
> > > ---------------
> > > Depuis mon mobile, désolé pour le style
> > >
> > >> Le 16 avr. 2016 à 15:56, Andrew Sullivan <ajs at anvilwalrusden.com> a
> écrit :
> > >>
> > >> It would still be very helpful to have something to read to explain
> > >> what exactly has changed here.  The CCWG has been asked about changing
> > >> this, and as far as I could tell there was not agreement that removing
> > >> the restriction is consistent with the CCWG consensus document.  Is
> > >> there some new argument about how the removal would be so consistent?
> > >> Because if not, I don't really see how the removal can happen without
> > >> re-opening the community-approved proposal.  Surely that'd be a bad
> thing.
> > >>
> > >> Best regards,
> > >>
> > >> A
> > >>
> > >>> On Sat, Apr 16, 2016 at 01:46:23PM +0000, Grace Abuhamad wrote:
> > >>> 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.
> > >>>
> > >>>
> > >>> Sent from my mobile device
> > >>>
> > >>> On Apr 16, 2016, at 07:58, Rinalia Abdul Rahim <
> rinalia.abdulrahim at gmail.com<mailto:rinalia.abdulrahim at gmail.com>> wrote:
> > >>>
> > >>> Grace, not just hard for those in Europe, but also in Asia.
> Nevertheless, I can make the time slots.
> > >>>
> > >>> Rinalia
> > >>>
> > >>> On Saturday, 16 April 2016, Grace Abuhamad <grace.abuhamad at icann.org
> <mailto:grace.abuhamad at icann.org>> wrote:
> > >>> Dear all,
> > >>>
> > >>> 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.
> > >>>
> > >>> 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.
> > >>>
> > >>> Option 1: Saturday 16 April at 21:00 UTC
> > >>>
> > >>> Option 2: Sunday 17 April at 20:00 UTC
> > >>>
> > >>> Option 3: Sunday 17 April at 21:00 UTC
> > >>>
> > >>> We acknowledge that these times are in small windows and late for
> our European colleagues, but we hope that these times can be accommodated.
> > >>>
> > >>> Thank you,
> > >>> Grace
> > >>> _______________________________________________
> > >>> bylaws-coord mailing list
> > >>> bylaws-coord at icann.org<javascript:;>
> > >>> https://mm.icann.org/mailman/listinfo/bylaws-coord
> > >>
> > >>> _______________________________________________
> > >>> bylaws-coord mailing list
> > >>> bylaws-coord at icann.org
> > >>> https://mm.icann.org/mailman/listinfo/bylaws-coord
> > >>
> > >>
> > >> --
> > >> Andrew Sullivan
> > >> ajs at anvilwalrusden.com
> > >> _______________________________________________
> > >> bylaws-coord mailing list
> > >> bylaws-coord at icann.org
> > >> https://mm.icann.org/mailman/listinfo/bylaws-coord
> > > _______________________________________________
> > > bylaws-coord mailing list
> > > bylaws-coord at icann.org
> > > https://mm.icann.org/mailman/listinfo/bylaws-coord
> >
>
>
> --
> Andrew Sullivan
> ajs at anvilwalrusden.com
> _______________________________________________
> bylaws-coord mailing list
> bylaws-coord at icann.org
> https://mm.icann.org/mailman/listinfo/bylaws-coord
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/bylaws-coord/attachments/20160417/fb1728a2/attachment-0001.html>