[CCWG-ACCT] Comments on the bylaws draft

[Andrew Sullivan]

Dear colleagues,

I've reviewed the bylaws by using "Redline - April 2 Draft Bylaws
compared to Current Bylaws (00780765-2xA3536)" and comparing with
"DRAFT-NEW-ICANN-BYLAWS-vers2APR".  I unfortunately did this using the
Word document which was converted by Pages, and some things were
imperfectly transferred, so I sometimes had to use the clean version
and couldn't see what was changed.  I'm aware that there's been an
update, but I just don't have time to go through that new version and
re-edit these comments to reflect that update (I'm at the end of the
IETF week, and I really didn't have time to do a good job on this this
week.  My apologies).

I've broken this into sections.  The IMPORTANT ISSUES section is where
I address issues that I think are at odds with the CCWG or CWG
document or their intent; anything in this section is something I
believe must be fixed for the bylaws to implement the community
consensus.  The POSSIBLE ISSUES section is where I note issues that
could be a problem because I don't really understand the text.  NITS
is what it says.

I hope these remarks are useful.  If you have follow-up questions,
please don't hesitate.  It is possible that colleagues of mine will
point out additional things over the next few days, and I'll pass
those along as I get them; but given the time lines I figured getting
these out as soon as possible was important.

    IMPORTANT ISSUES

1.1(a): the "root zone" of the DNS is missing compared to the CCWG
recommendation.  I think this is a mistake.

I understand the reasoning for this is that ICANN has involvement in
the policies in other than the root zone.  I contend that this does
not mean that ICANN is co-ordinating allocation or assignment in those
other zones.

ICANN actually does determine, according to its own policies, what
goes into the root zone.

ICANN does not determine what goes into other registries.  Instead, it
sometimes has agreements with others (all contracted TLDs and some
ccTLDs) that specify rules for _those_ registries.  Effectively, these
are conditions on ICANN's willingness to delegate from the root zone.
It's true that ICANN does that using its processes, but it does not do
that for all zones.  It doesn't even do it for all TLDs, since ccTLDs
are not subject to such policies.  Therefore, it just isn't true that
ICANN 'Coordinates the allocation and assignment of names in the
Domain Name System (“DNS”).'

I've heard an argument that claims that, since the previous versions
of the bylaws did not have the limitation to the root zone, therefore
this was not a limitation on ICANN.  But the effort in this Mission
work is exactly to arrange the Mission bylaw in accordance with
ICANN's actual responsibilities.  If ICANN's responsibility is only to
allocate and assign names in the DNS root, then that's what ought to
be in the bylaw.  I do not believe that ICANN has ever actually been
directly allocating or assigning names outside the DNS root, and if
the claim is that ICANN does that I think we have a fairly serious
disagreement.

Nothing about this Mission would prevent ICANN's role in co-ordinating
policies for those names delegated from the root, because those
policies follow directly from ICANN's policy control over the root
zone and its ability to extract contractual terms from operators of
TLD registries in return for delegation from the root.  I do not see
how the text as contemplated in the CCWG's report would undermine that
ability.  But I do see how the text as proposed in these draft bylaws
extends ICANN's responsibilities quite a lot more widely than ICANN's
actual responsibilities.  Therefore, I believe that the draft is not
in accordance with the community consensus, and the "root zone"
constraint ought to be reintroduced into the bylaw text.

1.1(d) is apparently the section that got added in order to deal with
the CCWG worry that the various agreements already in place might not
be in conformance with the clarified Mission.

    I. Is it ok to have the references to external agreements in the
    Mission?  They can change under (F).  It seems strange that the
    terms of the Mission could effectively be modified by these
    external agreements.  I note that the same reasoning led external
    agreements to be excluded from the text in earlier negotiations.

    II.  I have a lot of doubts about this section because some of the
    documents to which it refers aren't finished or else aren't yet
    written.  It's especially not clear what to do about the
    possibility that the documents could end up inconsistent with one
    another, in which case there'll be a serious problem (which will
    be hard to correct, since this is a fundamental bylaw).

    III.  The section seems quite a lot broader than the CCWG proposal
    Annex 5 (at line 48) contemplated in its instructions.  I am
    particularly worried that the strategic plan and operating plan
    are both explicitly included here.  Especially given the clause F,
    which explicitly permits renewals, including the plans as
    permitted means that anything at all can be allowed under this
    section.  I think this is a fatal flaw in the proposed text and in
    my opinion it must be fixed.  Otherwise, the whole point of having
    the clear, narrow Mission would be vitiated by this text.

4.2(c)(iii) Why is this restricted to "the resources for protocol
parameters"?  Why isn't it just "disputes relating to protocol
parameters"?  I'm quite sure the second is what's intended.  No
dispute of any kind involving protocol parameters is to be subject to
this reconsideration process, because the IETF already has a
reconsideration process for them.

Note: There's approximately the same issue in 4.3.c(iv).

17.2(b) The CWG proposal and the ICG proposal already transmitted to
NTIA does not make the additional TLD member inclusion of the CSC
dependent on the determination ccNSO and GNSO.  It is merely optional.
The CSC is not a creature of the ccNSO or GNSO or both, and their
consent to having such a member is not needed here (though they need
to approve the overall committee).  This is from ¶1327 on p. 102 of
the ICG report at
https://www.ianacg.org/icg-files/documents/IANA-transition-proposal-final.pdf.
It's true that document also doesn't say _who_ appoints such a
representative, but I suspect the goal was to make it possible for any
non-gTLD/non-contracted-TLD, non-ccTLD TLD authority to be able to
request that there be such a member.  So this bit should start with
"The CSC may…".  (Given that there is only one such policy authority
right now, I think it unlikely that the additional member will be
needed, but the bylaws should say what the CWG report asked for.)

18.8(a) makes rules about how candidates and liaisons are appointed,
but some of the appointments are or may be made by organizations not
subject to ICANN bylaws.  I don't see how this works.  External
organizations appoint people according to their own procedures,
surely?

19.5(b) has the same problem as 18.8(a).

Throughout, in several places, there are references to the "global
Internet community".  It appears that this was to identify a class of
interests that need to be represented (and it appears in older bylaws
in that use).  But in the current proposals, there are several places
where the global Internet community needs to be consulted, to develop
a process, and so on.  There's even a reference [in 4.3(n)(i), for
instance] to the "members" of the global Internet community; it's
extremely hard to know how one would determine such membership.  If
this term (or some other) is to be used, I think it needs to be
defined.  Alternatively, where action is needed, the parties that are
to act ought to be identified.

    POSSIBLE ISSUES

4.2(a) "ICANN shall have in place a process by which any person or
entity materially affected by an action or inaction of the ICANN Board
or Staff (i.e., employees and individual long-term paid contractors
serving in locations where ICANN does not have the mechanisms to
employ such contractors) (“Requestor”)" is slightly ambiguous.  The
"i.e." is presumably attempting to clarify what is "Staff", but could
possibly be misread to restrict the reconsideration requestors to the
class under "i.e.".  Perhaps, "where 'staff' means 'employees and
individual …'".

4.3(o)(vii) Should it also (or instead) refer to the cost shifting in (r)?

4.6(c) Do I understand correctly that items (ii) (B) and (C) are not
written yet?  Why are they in square brackets and not sentences?

17.2(g) I'm not actually sure the discretion here to the chair is
permitted.  The CWG proposal appears to have a hard requirement of 9
meetings in 12 months, and not 75%.  I don't care even a little bit
about this, but it should be checked for consistency with the CWG
recommendations.

18.5(a) I don't understand the reference to 18.2(c).  Should it be
18.3?

18.7(m) Does this mean that there is one liaison, and it may be
appointed by the IAB (or by someone else unspecified); or that there
is one possible liaison appointed by the IAB, and if the IAB doesn't do
it then that liaison doesn't happen?  I believe the latter is what's
intended.

19.5(a)(xiv) has the same problem as in 18.7.

19.5(d)(iii) appears to be unfinished

21.5 Given that the EC Chairs Council is supposed to change, is it
wise to place an address in the bylaws this way?  Is there some way of
making a future-proof reference?  Same with Decisional Participant.

22.4(b)(ii) It isn't clear to me why this distinguishes between the
IETF and IAB.  The IAB is the conduit for consultations with the IETF
from outside organizations.  I don't really care about this (I think
the duplication is harmless), but it's a little untidy.  I think in
the liaison language, the appointment comes from the IETF.  (Which is
true -- the IAB appoints the liaison, because IETF liaisons are
appointed by the IAB.)  You could probably drop either IAB or IETF.
The former is easier to consult with, because the latter could need a
consensus call to answer you.  (In general, liaison appointments from
the IETF are made by the IAB.)

    NITS

1.1(d)(iii) has a typo, I think.  I believe it is supposed to be
referring to 1.1.d(ii).

4.3(v) I think there's a duplicate v) here.

5.1(d)  Why is this in square brackets?  Stray from drafting?

7.2(a)(v) number agreement (One/Directors)

8.1 sshall

13.2(d)  I suspect that should be "TLG Procedures".

16.2(c)(v) Are the (x) and (y) in here some consequence of
auto-numbering gone wrong?

17.3(c)  brackets around "such organization"?

18.5(b) square brackets?

18.9(a) "All actions of the IFRT shall be taken by consensus of the
IFRT, which is where a small minority disagrees, but most agree."  The
antecedent of that "which" is apparently "the IFRT."  Perhaps, "All
actions of the IFRT shall be taken by consensus of the IFRT; for these
purposes, 'consensus' means where a small minority may disagree, but
most agree."  (This also solves the structural problem that unanimity
wouldn't meet the definition of consensus in the original sentence.)
Also, the second sentence of this clause isn't quite English.

19.4(b) seems to have a stray opening [ Also, it defines supermajority
for ccNSO but does not define Supermajority for the GNSO.  Is there
some significance to the additional capital letter?  (In general, I
must say, parts of both sections 18 and 19 make me a little worried.
The language seems flabby and reads as though it's written by people
who have mistaken portentousness for legalese.  It may be too late to
fix this, and I don't have good recommendations for what to do since,
alas, I didn't go to law school.  But I'm worried about bylaws
language that is hard to understand because of writing style.)

D.1.3(d) "Council selects, and/or, only if the Approval Action"
Because of the number of commas in the previous part of this sentence,
it's quite confusing.  Suggest a semicolon before and/or.


Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com