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.pd.... 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@anvilwalrusden.com