April 2016 - Accountability-Cross-Community

Preparation for Monday
by Thomas Rickert April 8, 2016

April 8, 2016

All, please note that we will send a document to the list containing all the items our group still needs to discuss in the next few hours. We would also like to ask those of you who have identified additional questions or concerns to please send those to the list at least 12 hours before our next call on Monday. Thank you and kind regards, Thomas --- rickert.net eco.de

3 5

Proposed agenda for CCWG ACCT Review of Draft Bylaws Meeting | Monday, 11 April 2016 @ 19:00 UTC
by MSSI Secretariat April 8, 2016

April 8, 2016

Dear All, In preparation for your call CCWG Accountability Review of Draft Bylaws Meeting<https://community.icann.org/x/FDuAAw> - Monday, 11 April at 19:00 - 21:00 (time converter<http://www.timeanddate.com/worldclock/fixedtime.html?msg=CCWG+Accountabilit…>), see below a proposed agenda: Proposed Agenda: 1. Opening Remarks 2. Second reading of question responses agreed on previous call 3. Resolution of remaining questions 4. Next Steps 5. ICANN 56 - Helsinki 6. AOB Documents for call: See wiki page here<https://community.icann.org/x/LYMHAw> Adobe Connect: https://icann.adobeconnect.com/accountability/ Thank you! Kind regards, Brenda

2 1

EC approval of Board-initiated removals
by Mueller, Milton L April 8, 2016

April 8, 2016

I think Andrew provides an irrefutable example of how making EC approval of board removals a rubber stamp opens the door to abuse at worst, or confusion and indecision at least. I think we need to return to this issue. I argued pretty strenuously in the Thursday call chat for EC approval (real, not automatic rubber stamp). We know that some kind of EC approval is _legally required_. So there is no avoiding this issue. Some argued that we had to make it "automatic" or a rubber stamp, because the CCWG did not explicitly say that it wanted to limit the board's ability to remove its own members. This is true as far as it goes, but the people who made that argument also acknowledged that this was largely an oversight rather than a deliberate decision. So, while the CCWG did not clearly say that it wanted the EC to approve board removals, it did not clearly say that it didn't, either. Those who favored the "rubber stamp" approach argued that this would be a "substantive change" in the CCWG proposal. I disagree completely - it is filling in a gap that was left inadvertently. Because of the legal requirement for EC approval, there is no avoiding some kind of a change. The issue is whether we make an intelligent adjustment to this problem or a blind, unintelligent one. To be fully consistent with the notion of a designator and an empowered community, we need to have the EC approve board-initiated removals, or else limit the board's removal power in some new way that forecloses the possibility of the scenario Andrew identified. --MM > -----Original Message----- > From: accountability-cross-community-bounces(a)icann.org > [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of > Andrew Sullivan > Sent: Thursday, April 7, 2016 11:58 AM > To: accountability-cross-community(a)icann.org > Subject: Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on > Draft Bylaws > > On Thu, Apr 07, 2016 at 04:34:14PM +0100, Seun Ojedeji wrote: > > SO: The way I understand it is that the EC powers is applicable on > > board action or inaction hence is not restricted in the manner you've > > described above. > > The proposed text I saw appeared to me to say that the EC would effectively > be required to rubber-stamp the decision. Maybe I misunderstood it; if so, > good. (The reason for the rubber stamp is that the EC is actually required to > make such an affirmation.) > > > I think we all should agree first that board should indeed be able to > > remove their colleague if they do wish and if the requirements meet. > > Well, yes and no. The point I'm trying to make is that this agreement could > represent an attack against an approach to additional accountability short of > the full replacement of the Board. Let me try to lay it out in more detail. > > Suppose the community were to decide that the Board was insufficiently > sensitive to $issue, and were to appoint someone to the Board who was > more sensitive to it. It is not too hard to imagine a case in which such a > member would be regarded by the rest of the Board as too disruptive and so > on. So, they remove the member. The Empowered Community permits the > removal. The community (whichever way the member is appointed) re- > appoints, the Board removes again, and so on. > > This could be short-circuited by simply making the required Empowered > Community action to be a real one, so that if the EC doesn't agree with the > Board's decision it can say, "No." > > I don't feel super strongly about this -- you could get the same result another > way (like by making it plain that's what's going to happen -- I don't believe > anyone likes that many trips to the dentist > -- or by just removing the Board). But since the EC is required to act anyway, > it seems one might as well use that occasion to allow the power to be used > effectively. > > Best regards, > > A > > > -- > Andrew Sullivan > ajs(a)anvilwalrusden.com > _______________________________________________ > Accountability-Cross-Community mailing list Accountability-Cross- > Community(a)icann.org > https://mm.icann.org/mailman/listinfo/accountability-cross-community

1 0

Two items on draft bylaws
by McAuley, David April 8, 2016

April 8, 2016

Dear Leon, Mathieu, and Thomas: In response to your request for participant feedback on the draft bylaws I would like to mention two items: First, about the IRP (Section 4.3). The draft bylaws give the IRP panel the right to change rules of procedure (Section 4.3.(n)(ii)). In this respect the panel seems unconstrained, only having to publish revisions and possibly to get a consensus (not clear of whom - the COs, the EC, the panel, other?). As I recall, the final proposal did not give the panel this right. It seems to me that the community and Board need to retain some oversight here. Annex 07, paragraph 63, indicates that rules of procedure are to be created by the community and approved by the Board. It is true that Annex 07, paragraph 55 says that, "Panel decisions would be determined by a simple majority. Alternatively, this could be included in the category of procedures that the IRP Panel itself should be empowered to set." But this indirect reference to setting rules does not appear to justify displacing the community-development and Board-approval rights when it comes to rules of procedure. And second, about human rights, specifically an implication in Article 27.3.(c) that HR claims might be a proper subject for RR or IRP after the FOI is developed. This implication is not in the Annex 06 bylaw text (paragraph 23), although it appears in explanatory text (paragraph 19). But both bylaw text and explanatory text say that acceptance of the FOI will depend on the same processes followed in WS1, and bylaw text makes clear that the FOI has to be approved by the Board after it follows the same process and criteria it used in WS1. In my opinion it is a mistake to insert this implication in "real" bylaws as the issue is important as well as complex and the WS2 FOI group should have a chance to debate the merits. Thank you, David McAuley

4 3

Comments on the bylaws draft
by Andrew Sullivan April 8, 2016

April 8, 2016

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.p…. 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(a)anvilwalrusden.com

1 0

Re: [CCWG-ACCT] Issue Item 3
by Seun Ojedeji April 7, 2016

April 7, 2016

Sent from my LG G4 Kindly excuse brevity and typos On 7 Apr 2016 2:48 p.m., "Edward Morris" <egmorris1(a)toast.net> wrote: > > Hi everybody, > > I am writing with regard to issue 3, reiterating my request on the call today to change could to should in paragraph 2 of the CCWG Response to Issue 3 contained in the document "CCWG Response - Bylaws - Questions 6Apr16V2.pdf. > > The goal is simply to make it crystal clear that the Board's decision to redact is subject to challenge, the perhaps sensitive sensitive nature of the information not precluding same. > SO: There is a whole section for inspection rights, if there is any doubt that the redaction can be challenged, then i would think any clarification on that should be in Section 22.7 which addresses that issue. I think it's neater to avoid repeating stuffs in the bylaw as saying them again does not necessarily make it more binding than it already is. That said, I have no strong opposition to what you've suggested. Regards > Thanks for considering, > > Ed > > > _______________________________________________ > Accountability-Cross-Community mailing list > Accountability-Cross-Community(a)icann.org > https://mm.icann.org/mailman/listinfo/accountability-cross-community >

1 0

CCWG - Answers to some of the questions regarding Bylaws drafting
by Bernard Turcotte April 7, 2016

April 7, 2016

All, Please find attached the CCWG-Accountability (CCWG) answers to some of the questions presented by the legal teams regarding the drafting of Bylaws. The CCWG has approved the answers to questions: 3,4,5,7,26,27,28,30,31,32,34. Additionally the CCWG would request the lawyers to redraft question 29 to properly match to the CCWG report and not refer to the carve-out. The CCWG will be holding an additional meeting Monday April 11th (and possibly the 12th) to complete answering the remaining questions for April 13th. Thank You. Bernard Turcotte for the CCWG Co-Chairs Mathieu Weill, Thomas Rickert, Leon Sanchez

1 0

Notes-Recordings-Transcript link for CCWG Accountability "Review of Draft Bylaws" Meeting - 7 April 2016
by MSSI Secretariat April 7, 2016

April 7, 2016

Hello all, The notes, recordings and transcripts for CCWG Accountability "Review of Draft Bylaws" Meeting - 7 April 2016 will be available here: https://community.icann.org/x/XBWAAw A copy of the notes may be found below. Thank you. Kind regards, Brenda Notes These high-level notes are designed to help you navigate through content of the call and do not substitute in any way the transcript. 1. Opening Remarks MW * Working methods - reminder of agreements from past meetings - the top priority is answering the lawyer's questions for drafting. * A certification that the Bylaws meet our requirements has been delegated to our legal teams and will be completed. * Principal when reviewing Bylaws - ensure the language meets our requirements in the supplemental report - no more and no less. We need to avoid going away from the requirements or going beyond them. * The CCWG has until April 9 to raise issues - the lawyers will them produce a new version. * We will review our procedures going forward at the end of our call today. 2. Second reading of question responses agreed on previous call TR (Approved = will be sent to lawyers as the CCWG response to the question, Agreed = the CCWG still needs to confirm). * Q1 - Approved. * Q2 - Agreed as is revisit Monday 11th. * Q3 - Approved with Ed Morris point (see email) * Q4 - Approved * Q5 - Approved but for ICANN to confirm details. * Q6 - need to redraft answer to ensure it is clear that this power of the Board has not been addressed by the CCWG and therefore should not be changed (TR) * Q7 - Approved. * Q25 - Agreed. * Q26 - Approved. * Q27 - Approved. * Q28 - Add the requirement for the Board to have a rationale for calling such a community forum. Approved. * Q29 - Instructions by co-chairs to lawyers to redraft question 29 to properly map to the CCWG report and not refer to the carve out. * Q30 - Approved as is. * Q31- Approved as is. * Q32 - Approved * Q33 - This question needs to be reframed for consideration by the CCWG. * Q34 - Approved. 3. Resolution of Additional questions (first readings) * AQ1 - * AQ2 - * AQ3 - Linked to Q29 (?) * AQ4 - * AQ5 - * AQ6 - * AQ7 - * AQ8 - 4. Next Steps * Monday April 11th 19:00 UTC to continue review * Tuesday April 12th (if needed) 12:00 UTC to complete review 5. ICANN 56 - Helsinki * To be discussed on the April 11th call. 6. AOB * None 7 Adjourned

1 0

Re: [CCWG-ACCT] [bylaws-coord] A substantive question on Mission
by Andrew Sullivan April 7, 2016

April 7, 2016

Hi, On Thu, Apr 07, 2016 at 02:32:36PM +0000, John Curran wrote: > For avoidance of doubt, the Service Level Agreement for IANA Numbering Services is > complete and it is the result of a open and transparent process which included multiple > public updates and comment periods. It implements the principles outlined for such > an agreement as specified the IANA Stewardship proposal from number community. > Hopefully that is not one of the documents that you express concern about, but wanted > to make the status clear to the others on the bylaws coordination list. I believe that that particular case isn't especially tricky, because I find it impossible to believe that the number community would now agree to anything that hadn't been already widely vetted and so on. So it is one of the agreements that hasn't taken effect yet, but it's not one where I (at least) worry about the future contents. At the same time it's still true that it's not an agreement in effect now. Indeed, even the IETF's MoU with the last supplemental agreement -- the one needed to meet the protocol parameters piece of the ICG proposal -- isn't in effect now, either. It seems strange to try to evaluate such a text. Best regards, A -- Andrew Sullivan ajs(a)anvilwalrusden.com

1 0

Issue Item 3
by Edward Morris April 7, 2016

April 7, 2016

Hi everybody, I am writing with regard to issue 3, reiterating my request on the call today to change could to should in paragraph 2 of the CCWG Response to Issue 3 contained in the document "CCWG Response - Bylaws - Questions 6Apr16V2.pdf. The goal is to make it clear that requesting parties may challenge through appropriate channels any and all redactions made by the Board in information released via either recording or transcript from the Reconsideration process. Some parties have had difficulty in the past obtaining information using the DIDP, where seemingly reasonable restrictions on information release contained in the Defined Conditions of Nondisclosure (listed here: https://www.icann.org/resources/pages/didp-2012-02-25-en ) have allegedly been used in an expanded way by Board and staff to decrease organisational transparency. DCND/DIDP appeals procedures have proven to be unnecessarily opaque and operationally unsatisfactory. We want to avoid that here. Section 22.7.e of the April 2nd Bylaws proposal, relating to Inspection, may serve as a model for form if not content. It may be appropriate to direct appeals off this nature directly to an I.R.P. but I would not to be opposed if the whole canalopy of accountability mechanisms become available to the requestor. The goal is simply to make it crystal clear that the Board's decision to redact is subject to challenge, the perhaps sensitive sensitive nature of the information not precluding same. Thanks for considering, Ed

1 0