[At-Large] ACCOUNTABILITY Restart - Was Re: ICANN Accountability Mechanisms
jeff at jjnsolutions.com
Tue Jan 4 17:17:07 UTC 2022
I totally agree with you that for ICANN Accountability purposes the Delegation of Authority Policy should say that any responsibility/obligation of the ICANN Board that is delegated to staff or to a third party shall remain an obligation/responsibility of the Board despite such delegation. But that is not what the policy states. Nor is that what the Bylaws would allow.
Section 4.2(s) of the bylaws state: “If the Requestor believes that the Board action or inaction for which a Reconsideration Request is submitted is so urgent that the timing requirements of the process set forth in this Section 4.2 are too long, the Requestor may apply to the Board Accountability Mechanisms Committee for urgent consideration. Any request for urgent consideration must be made within two business days (as calculated by local time at the location of ICANN's principal office) of the posting of the resolution at issue. A request for urgent consideration must include a discussion of why the matter is urgent for reconsideration and must demonstrate a likelihood of success with the Reconsideration Request.”
As seen in the BAMC Response to Reconsideration Request 21-3<https://www.icann.org/en/system/files/files/reconsideration-21-3-dot-hip-hop-bamc-recommendation-request-16dec21-en.pdf> – ICANN has only adopted the plain meaning of Section 4.2(s) and is not willing to entertain new arguments about what should be considered. It states: “In any event, an urgent request for reconsideration, which is subject to speedy resolution under Section 4.2(t) of the Bylaws, is not the appropriate vehicle to advance the novel argument that Section 4.2(s) of the Bylaws should be read more expansively than what—as Requestor acknowledges—its plain language allows.”
Therefore, even though I agree that Board actions that are delegated to the staff should be covered just as Board Actions or Inactions are, but ICANN will not interpret the Bylaws in this manner without making the changes.
So, I think we need to:
a) Change the Delegation Policy to include this concept of the Board being ultimately responsible for the activities it delegates staff for purposes of the Accountability Mechanisms; and
b) We then need to define the timing of the filing of an Urgent Request. It cannot continue to be a requirement that an action be filed within two days of a board resolution.
Otherwise, ICANN will continue to interpret this provision literally and will REJECT all claims for Urgent Reconsideration Requests if (a) there is no Board Resolution (which makes it hard to challenge INACTION); and/or (b) it involves only staff action (even where such staff action was delegated by the Board). ICANN has now made it clear that a literal meaning of the words in the Bylaws controls.
Thanks again for discussing the substance.
[cid:image001.png at 01D80163.7020D6A0]
Jeffrey J. Neuman
Founder & CEO
JJN Solutions, LLC
E: jeff at jjnsolutions.com<mailto:jeff at jjnsolutions.com>
From: Carlton Samuels <carlton.samuels at gmail.com>
Sent: Tuesday, January 4, 2022 11:40 AM
To: Jeff Neuman <jeff at jjnsolutions.com>
Cc: Evan Leibovitch <evan at telly.org>; Javier Rua <javrua at gmail.com>; Olivier MJ Crépin-Leblond via At-Large <at-large at atlarge-lists.icann.org>
Subject: Re: [At-Large] ACCOUNTABILITY Restart - Was Re: ICANN Accountability Mechanisms
I really don't understand why a duty of the Board delegated to staff would inoculate it from the constraints in byelaw or shield it from constraining counteractions envisioned by those byelaws. The rule of agency should apply.
An example from the edge of empire where the rules are largely from the same root as the governance framework that corrals the ICANN board would probably best explain my puzzle. I chair a school board. The regulations - analogous to the bye-laws - allow the delegation of duties to which the board is obligated by an affirmative resolution of the board to the administration of the school. We delegated the hiring and operational supervision of teachers to the administration. Professional misconduct is alleged by a teacher hired by the administration. We are obliged to endorse and/or direct any lawful countervailing action by the administration. But for the law and oversight education ministry, it is the Board that is accountable and is constrained to act as the regulations determine. Everybody comes to the Board, not the hirelings.
It seems to me that all the ICANN Board needs to do is to acknowledge that any obligation of the Board that was delegated by an affirmative resolution is and remains an obligation of the Board and the attendant instruments are neither unmoored or marooned by delegation. Because anything otherwise would be a way of evading, indeed nullify, every duty and obligation to which it is obligated. You are alleging that it has relieved itself of responsibility - and accountability! - by hiding behind the delegation. That, if so, would be an example of the kind of behavior the Empowered Community should have a stake in correcting. I'm wondering whether you called on the GNSO and CCNSO to take this into consideration?
Carlton A Samuels
Strategy, Process, Governance, Assessment & Turnaround
On Mon, Jan 3, 2022 at 5:28 PM Jeff Neuman via At-Large <at-large at atlarge-lists.icann.org<mailto:at-large at atlarge-lists.icann.org>> wrote:
Ok, all this has been a great discussion on Internet Governance theory, but can we bring this back to the subject at hand with respect to accountability and what practical steps we can take to address the accountability issues.
What steps do we need to do to formally introduce this issue into the At-large and get addressed by the ALAC?
The two issues are as follows:
1. Urgent Requests for Reconsideration and closing unintended loopholes; and
2. Extending Whistleblowing Claims to allow community members to file claims (not just employees).
* URGENT RECONSIDERATION REQUESTS:
* With respect to #1, as Reconsideration Request 21-3 has shown, although there is a process for the Urgent Consideration of Reconsideration Requests in the Bylaws, that provision, which was not changed as a result of the IANA transition, is no longer fit for purpose.
Let me explain:
A) The ICANN Bylaws allow the filing of Reconsideration Requests as a result of either board action or inaction, or for Staff action or inaction. Prior to the transition, the Bylaws states that Reconsideration requests could be filed for ICANN action or inaction. The CCWG and Accountability teams in 2014-2016 believed that “ICANN action or inaction” meant either ICANN Board or ICANN staff action or inaction.
B). However, Although most of Reconsideration Request section in the Bylaws was heavily modified during the CCWG process, the community inadvertently never amended the process for Urgent Reconsideration Requests. Not sure why that was.
C). The CCWG wanted to make sure it was clear that Reconsideration Requests in general was not just for ICANN Board action or inaction, but also for ICANN Org’s action or inaction.
D). So although Reconsideration Requests now apply to staff actions/inactions, the Urgent Requests section (because the wording was not changed - or because ICANN staff deliberately did not want urgent requests to apply to it), Urgent Reconsideration requests now has been interpreted to apply only to Board Action or Inaction. I do NOT believe this was intended. But even if it were, it is time to change that.
So, in order to file an Urgent Request for Reconsideration, the Bylaws state that it must be filed within 2 days after a Board Resolution.
1. Because Staff action (or inaction) is generally not in response to an ICANN Board Resolution, because there is no ICANN Board resolution, you you cannot file an urgent request. [This is why Reconsideration Request 21-3 failed to be treated as “Urgent”]
2. In addition, it is also likely that Urgent Requests for Reconsideration for Board inaction will also not succeed. Think of the most common case where the community needed the Board to pass a resolution on something, but they failed to do so. If you wanted to challenge that on an urgent basis, you could not because the Board inaction is the failure to pass a resolution. And since there was no resolution, you cannot file an urgent request.
AND HERE IS WHERE IT GETS WORSE…..
After the transition was approved, in late 2016, the ICANN Board passed a resolution to approve a new delegation of authority policy (See https://www.icann.org/en/system/files/files/delegation-of-authority-guidelines-08nov16-en.pdf). That policy allows the ICANN Board to delegate certain responsibilities that it has to ICANN staff without the need for the Board to pass a resolution.
ICANN Org legitimately stated this was needed especially where now you have 1200+ TLDs, Registry Services requests, amendments, etc. If every modification required a Board Resolution this would be too much of a burden for the ICANN Board.
But under the law of unintended consequences, any decision the ICANN Board delegates to the ICANN staff may now never be the subject of an Urgent Request for Reconsideration. What if, for example, the ICANN Board states that once it passes the new gTLD Program for subsequent rounds, ICANN staff had the sole discretion (without Board approval) to implement every aspect of the program including setting the fees, and resolving any and all remaining items. And lets say ICANN staff (without a Board Resolution) states a few days before opening the window, that no entity may apply for a gTLD if it already has 10,000 names under management combined with respect to any TLDs for which it is a registry operator, back-end registry operator or DNS provider.
If this doers not require a Board Resolution, you cannot oppose this new policy via an Urgent Reconsideration Request because there was no resolution.
Between the inability to challenge staff action or inaction urgently, or even Board inaction urgently, combined with the ability of the Board to delegate important items to staff without a resolution, the Urgent Reconsideration Request has been gutted.
* Whisteblowing and Retaliation. My article in CircleID (https://circleid.com/posts/20211230-icannas-accountability-mechanisms-in-name-only) goes into some more detail on this, but in 2016 ICANN hired an outside firm to review its Whisteblower policies. That firm made a recommendation to ICANN that it consider revising its Whistleblowing policies to allow the filing of complaints by parties other than employees because they were worried about community members filing complaints against ICANN and having no protection from retaliation. This would of course disincentive anyone from raising issues if they saw that ICANN were violating its bylaws.
ICANN responded to that report by stating that the community would consider it as part of Work Stream 2….but somehow that never happened.
And now we have an example of a party filing a complaint against ICANN and being retaliated against for having done so. The community needs to take this issue up as was recommended by the outside group to reviewed ICANN’s Whistleblower policies
These are what need to be addressed.
Jeffrey J. Neuman
Founder & CEO
JJN Solutions, LLC
Jeff at JJNSolutions.com<mailto:Jeff at JJNSolutions.com>
From: At-Large <at-large-bounces at atlarge-lists.icann.org<mailto:at-large-bounces at atlarge-lists.icann.org>> on behalf of Evan Leibovitch via At-Large <at-large at atlarge-lists.icann.org<mailto:at-large at atlarge-lists.icann.org>>
Sent: Monday, January 3, 2022 11:08:25 AM
To: Javier Rua <javrua at gmail.com<mailto:javrua at gmail.com>>
Cc: Olivier MJ Crépin-Leblond via At-Large <at-large at atlarge-lists.icann.org<mailto:at-large at atlarge-lists.icann.org>>
Subject: Re: [At-Large] ICANN Accountability Mechanisms
On Mon, 3 Jan 2022 at 07:15, Javier Rua via At-Large <at-large at atlarge-lists.icann.org<mailto:at-large at atlarge-lists.icann.org>> wrote:
Thx @OCL. I resolve to stop using the word “multistakeholderism”!
I will defend the term, and continue to use it based on my personal understanding which I believe is sensible and easily understandable.
To me, multistakeholderism ("m17m"*) is a political philosophy that all parties affected by a governance process ought to have a voice in that process, distinct from democracy in that it seeks a balance between populism and technical expertise.
There are multiple implementations of m17m, many here have experienced a few, I offer some examples:
* ICANN's of course
* American political town halls
* The Netmundial conference in São Paulo
* IETF, complete with humming-based decision-making
* ISO and many standards-making bodies
Some are better than others, and some (most?) only present a facade of broad participation layered over a real process controlled by insiders. But as an aspirational approach to governance, to me true m17m is worth pursuing.
(*) - I use m17m for "multistakeholderism" much like i18n<https://lingoport.com/what-is-i18n/> is used as an abbreviation for "internationalisation", and I'm lazy when I type. The abbreviation MSM (MultiStakeholder Model) to me means something different, the specific form of m17m used by ICANN which has essentially appropriated the term.
At-Large mailing list
At-Large at atlarge-lists.icann.org<mailto:At-Large at atlarge-lists.icann.org>
At-Large Official Site: http://atlarge.icann.org
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 67520 bytes
More information about the At-Large