[CCWG-ACCT] Draft Bylaw comments

Kavouss Arasteh kavouss.arasteh at gmail.com
Mon May 9 11:50:02 UTC 2016


Dear All
While I agree with concept but there is concern about outside panelist,
What are the prerequisite criteria to be considered qualified as panelist . Who prepare those criteria.
Regards
Kavousd   



Sent from my iPhone

> On 9 May 2016, at 06:44, Alan Greenberg <alan.greenberg at mcgill.ca> wrote:
> 
> Following a not quite comprehensive review of the Draft Bylaws, focusing on the areas where I had the most involvement and/or concern, I have drafted a number of comments.
> 
> If there are any sections where other who have reviewed the Bylaws can tell me I have mis-read anything, please let me know.
> 
> Alan
> 
> ========================
> 
> Section 4.3(k)(ii)
> "In the event that a Standing Panel is not in place when an IRP Panel must be convened for a given proceeding or is in place but does not have capacity due to other IRP commitments or the requisite diversity of skill and experience needed for a particular IRP proceeding, the Claimant and ICANN shall each select a qualified panelist from outside the Standing Panel and the two panelists selected by the parties shall select the third panelist.
> 
> I would suggest that first "Shall" should be "may". It is possible if the issue is capacity, diversity of skill or experience, there may be some panelists that qualify, even if there are not three.
> ==========
> 
> Section 4.6(b)(ii)
> "The issues that the review team … may assess are the following" does not properly implement CCWG Annex 9, paragraph 84 "Issues that may merit attention in this review include:".
> 
> The original AoC mandated the list that follows. Paragraph 84 did not require that an ATRT address them all, but also allowed an ATRT to address other issues not listed. The Bylaw language is prescriptive and limits the topics.
> ==========
> 
> Section 4.6(e)(v)
> During the CCWG discussions on the interval between reviews, the issue of ICANN immediately being in default on the WHOIS/RDS review was never raised. Moreover, since those discussions were held, the GNSO new RDS PDPWG has been convened and is well underway. It is reasonably clear that the people in the volunteer community who would likely participate in an RDS review significantly overlap with those who are heavily involved in the RDS PDP. To schedule an RDS Review soon after the Bylaws are enacted would be serious error and will only serve to slow the work of the PDP - a PDP that even now may go on for quite some time.
> 
> It is clear that there is work that needs to be done that would fall under the auspices of a full blown PDP. We need a good picture of how the various current WHOIS/RDS efforts mesh together. We need to assess how the recommendations of the first WHOIS review are being implemented and their impact, as well as other WHOIS/RDS related activities unrelated to that last AoC review.
> 
> But these efforts, as important as they are, do not need to be done by a full-blown AoC-like review. Most of the work can be done by staff. To the extent that "staff cannot be trusted" (something that I question, but will address), I am others in the community will gladly act as a sounding block and review their work. [For the record, I was the person on the ATRT2 who did the full analysis of the WHOIS RT Recommendation implementation, so I have some idea of what I am talking about.]
> 
> The Bylaws for the organizations review all have explicit time limits in them, but also have the words "if feasible". That was true even when the organization review interval was (foolishly) three years instead of the five years it was quickly changed to. "If feasible" allowed the Board to save an immense amount of wasted community expense and ICANN dollars. We need some wriggle room in the current case as well.
> 
> I strongly suggest that the draft Bylaws be revised to allow additional flexibility to defer the RDS review until there is a real RDS to review, and would even suggest that once implemented, they soon after be amended to add the missing "if feasible".
> ==========
> 
> Section 6.1(g)(iv)
> "how the Decisional Participant determines whether an issue subject to a petition has been resolved,"
> 
> In all of the other Roman Numeral phrases, there are specific processes to design or rules to write. This one is out of place. In any given case, the process to decide whether the issue has gone away will depend on exactly what that issue was. There does not seem to be a way to write that generic process in any way that will prove useful when the need to "determine" arises. I suggest that this section be deleted.
> ==========
> 
> Section 6.2(a)(v)
> "Articles" should be "Articles of Incorporation" (Articles alone would refer to any of the 27 Articles within the Bylaws).
> ==========
> 
> Section 7.4(d)
> "No person who serves on the EC Administration while serving in that capacity shall be considered for nomination or designated to the Board, nor serve simultaneously on the EC Administration and as a Director or Liaison to the Board."
> 
> This seems both problematic and uncalled for, and I do not believe is based on anything in the CCWG proposal. There is a more reasonable restriction in 7.4 (b) that says someone serving on the Board cannot occupy other positions. But in this case, the EC Administration (the AC/SO Chairs or other delegates) can only act on instructions they are given. To restrict them from being considered means that they cannot even submit a confidential application to the NomCom, a restriction that is placed on no one in ICANN except those actually sitting on the current NomCom.
> ==========
> 
> Section 7.11(a)(i)(B)
> For removal of a Board member by the Board, the current Bylaw says a 3/4 majority vote of all Board members, except the member subject to the removal is required. The revision omits the exclusion allowing that director to participate in the vote. What is the compelling rationale for this change which is not related to any CCWG recommendation?
> ==========
> 
> Section 7.12(b)
> This section stipulates what process should ensue after the entire Board (except the President) is removed because they are mentally unsound, convicted of a felony, or being found by a court to have breached their duty as a Director. Presumably the last Board member is removed by action of the President, the last person standing, who somehow convinced the last Director to remove themselves (for the 3/4 vote).
> 
> This is also the only reference I could find for AC/SO appointing Interim Directors which is required in the case of the EC removing the entire Board. But in that case, the Interim Directors were supposed to be named BEFORE the final vote so that the Interim Board would be ready to immediately take office as required by Paragraph 97 of Annex 4 ("Having a Board in place at all times is critical to the operational continuity of ICANN and is a legal requirement").
> ==========
> 
> Section 12.2(d)(ix)(F)
> "Rules of Procedure" is a defined ALAC document. I am not sure if that is sufficient to justify upper case here , but regardless, I would assume the usage should be consistent throughout the sentence. I note that in Annex A, terms such as "Policy Development Process Manual", "Initial Report", "Final Report" and other terms are all capitalized.
> ==========
> 
> Annex D, Section 1.2
> The term PDP is used here. That is a defined term in the Bylaws referring only to the GNSO. My understanding is that the section related to a Bylaw change as a result of any formal policy development process from an SO. The ccNSO uses the defined term "ccPDP" and the ASO section is silent on what their policy process is called.
> ==========
> 
> Annex D, Section 1.4(b)(i-ii)
> The higher threshold should apply not only to Fundamental Bylaws, but also to the Articles of Incorporation.
> ==========
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community


More information about the Accountability-Cross-Community mailing list