[ALAC] REVISED: My comments on Draft Bylaws

Sat May 21 17:33:08 UTC 2016

I agree with both these comments and recommendations, Alan.
On 20/05/2016 5:48 pm, "Alan Greenberg" <alan.greenberg at mcgill.ca> wrote:

> Here are my revised comments.
>
> Thanks to all for your feedback. It is a much stronger statement as a
> result.
>
> They are submitted Public Comment on my own behalf. I believe that Based
> on the comments so far, I have the full support of the ALAC on the first
> item, and significant but not full support on the second. I will wait until
> tomorrow near the end of the comment period to post a message about ALAC
> support (adjusting the above if necessary based on further input).
>
> Also attached is a redline version showing the changes from the earlier
> version.
>
> Alan
>
> =============================
>
>
> *Background: *The Affirmation of Commitment (AoC) Reviews are being
> integrated into the Bylaws. The AoC called for the reviews to be held every
> three years, but was unclear as to how the three years was to be measured.
> The three years has been interpreted flexibly to allow more time between
> some reviews and the Board has deferred some reviews due to community
> overload (with the agreement of the NTIA, the AoC co-signer). The CCWG
> Proposal required the new reviews to be carried out no less frequently than
> every five years, measured from the start of one review until the start of
> the next one. It was recently realized that the last WHOIS review started
> in October 2010, so when the new Bylaws are adopted, we will already be
> several months past the October 2015 date for the next one to start and
> will need to initiate the next one immediately.
>
> Since the required review is on Registration Directory Services Review,
> renamed from WHOIS Review, we would technically NOT be in default, since
> there never has been an "RDS Review". But it is assumed that this
> distinction will not affect ICANN's actions.
>
>
> *Section 4.6(e)(v) *During the CCWG discussions on the interval between
> the 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 PDP WG 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 AoC-like Review. 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", I and others in the community will
> gladly act as a sounding board 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 current Bylaws for the organizational reviews 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 or RDS plan
> to review, and would even suggest that once implemented, the new Bylaws
> soon after be amended to add the missing "if feasible".
>
>
> =============================
>
> *Background: *The CCWG Proposal requires the Empowered Community (EC) to
> take a variety of actions but was not specific on exactly how this would
> happen or what people would take responsibility for ensuring that the
> actions are carried out. As a result this had to be addressed during Bylaw
> drafting. The concept of the EC Administration was created, embodied by the
> Chairs (or other delegates) of the AC/SOs participating in the EC.
>
> Along with the creation (or perhaps naming, since there was always a need
> for such a body/group) of the EC Administration, a section was added to the
> draft Bylaws placing restrictions on the people involved in the EC
> Administration.
>
>
>
> *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."
>
> Lawyers Comments (in reply to my early raising of this issue):
> On March 31, 2016, counsel posed the following question to the Bylaws
> Coordination Group and received confirmation that the disqualification in
> Section 7.4(d) be included in the Bylaws: "Confirm that chairs of the
> Decisional Participants and persons designated by the Decisional
> Participants to serve on the EC Chairs Council cannot be nominated or serve
> on the ICANN Board. Such a provision would be consistent with other
> provisions in the current Bylaws, which provide that (a) "no person who
> serves in any capacity (including as a liaison) on any Supporting
> Organization Council shall simultaneously serve as a Director or liaison to
> the Board (Article VI, Section 4.2)" and (b) persons serving on the
> Nominating Committee must be "neutral and objective, without any fixed
> personal commitments to particular individuals, organizations, or
> commercial objectives in carrying out their Nominating Committee
> responsibilities” (Article VII, Section 4.4)."]
>
> I note that the term "nominated" as used in the new Bylaws is used in the
> sense of the current Nominating Committee. Once a person is "nominated" by
> the NomCom or an AC/SO, they will become a Director once the EC takes the
> appropriate action (and the EC has no option to NOT take such action).
> However, this is confusing terminology, because an AC/SO may well have a
> nomination process used to select candidates who will then vie for the
> actual AC/SO selection.
>
> I believe that the Bylaws Coordination Group may have erred in its reply
> and moreover, the Bylaw drafters went farther than was required in
> implementing that response. There are several reasons.
>
> 1. The CCWG has been very careful to only implement exactly what is
> specified or implied in the CCWG Proposal. The EC Administration is not
> explicitly named, but is implied in Proposal Paragraph 178, bullet 8 and
> elsewhere. There is no mention of restrictions such as those in this
> proposed Bylaw, and as described below, I can see no compelling reason to
> vary from the CCWG Proposal.
>
> 2. I cannot understand what the relationship is between the EC
> Administration and the rules that apply to the NomCom. The NomCom makes
> decisions. The AC/SO Chairs or other delegates who participate in the EC
> Administration have no discretion whatsoever. They MUST follow the
> directions of the entity nominating or removing a director.
>
> 3. Given that lack of ability to influence outcomes, I find it
> unreasonable to restrict such a person from submitting an SoI to the NomCom
> or to their own AC/SO as a potential director (ie to be "considered").
>
> 4. I would find it quite reasonable that they would have to surrender (or
> be deemed to have surrendered) their EC Administration seat if they are
> actually nominated (nominated in the sense of the Bylaws - will actually
> serve on the Board once the EC Designates them). This is in line with the
> reference to serving "simultaneously"
>
> 5. I note that the wording in the proposed Bylaws is different from what
> was asked. The March 31st question was "Confirm that chairs of the
> Decisional Participants and persons designated by the Decisional
> Participants to serve on the EC Chairs Council cannot be nominated or serve
> on the ICANN Board.". The draft Bylaws extend that to "considered for
> nomination" which is a much wider group.
>
> 6. The path of AC/SO Chair to Director is not unreasonable - both require
> high degree of confidence in the person expressed by the AC/SO. And to be
> blunt, arguably two of our best currently seated AC/SO Directors have
> followed exactly that path, as did the current Board Chair (although in
> that case, since the SSAC has chosen not to be part of the EC, the rule
> would not be applicable).
>
> I strongly suggest that Section 7.4(d) be replaced by: “No person may
> serve simultaneously on the EC Administration and as a Director or Liaison
> to the Board. If a member of of the EC Administration is appointed as a
> Liaison to the Board, that person must be replaced by their AC/SO on the EC
> Administration prior to the Liaison appointment becoming effective. If a
> person is nominated by the Nominating Committee or an AC/SO to become a
> Director, that person must be replaced by their AC/SO on the EC
> Administration prior to the EC Administration designating that person as a
> Director and prior to that person taking part in any Board activities as an
> observer.”
>
> _______________________________________________
> ALAC mailing list
> ALAC at atlarge-lists.icann.org
> https://atlarge-lists.icann.org/mailman/listinfo/alac
>
> At-Large Online: http://www.atlarge.icann.org
> ALAC Working Wiki:
> https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/alac/attachments/20160521/04af3ede/attachment.html>