Re: [CCWG-ACCT] Bringing AoC Reviews into ICANN Bylaws, v5.4 reflecting Paris and new Non-Disclosure rule
Update to reflect discussions in WP1 yesterday, regarding the non-disclosure provision. CCWG is proposing giving AoC Review Teams access to ICANN internal documents, which includes some information that is proprietary or sensitive. This creates two disclosure concerns: First, what to do if ICANN redacts or withholds any information sought by a review team? Second, of information that is shared with the review team, how to determine which information the Review Team must not disclose — in its report or otherwise? A subset of WP1 members (Alan Greenberg, Greg Shatan, James Gannon, Jordan Carter, and me) drafted new text, shown below and on page 3 of the attached doc. Confidential Disclosure to Review Teams: To facilitate transparency and openness regarding ICANN's deliberations and operations, the review teams, or a subset thereof, shall have access to ICANN internal information and documents. If ICANN refuses to reveal documents or information requested by the review team, ICANN must provide a justification to the review team. If the review team is not satisfied with ICANN’s justification, it can appeal to the Ombudsman and/or the ICANN Board for a ruling on the disclosure request. For documents and information that ICANN does disclose to the review team, ICANN may designate certain documents and information as not for disclosure by the review team, either in its report or otherwise. If the review team is not satisfied with ICANN’s designation of non-disclosable documents or information, it can appeal to the Ombudsman and/or the ICANN Board for a ruling on the non-disclosure designation. A confidential disclosure framework shall be published by ICANN. The confidential disclosure framework shall describe the process by which documents and information is classified, including a description of the levels of classification that documents or information may be subject to, and the classes of persons who may access such documents and information The confidential disclosure framework shall describe the process by which a review team may request access to documents and information that are designated as classified or restricted access. The confidential disclosure framework must provide a mechanism to escalate and/or appeal the refusal to release documents and information to duly recognized review teams. From: Steve DelBianco Date: Monday, July 20, 2015 at 2:01 PM To: "wp1@icann.org<mailto:wp1@icann.org>" Cc: Jordan Carter, Avri Doria Subject: Bringing AoC Reviews into ICANN Bylaws, v5 reflecting Paris Saturday discussion Updated to reflect Saturday in Paris, where we said that commitments stated within the new gTLD and WHOIS reviews would stay in that section of the Bylaws, instead of moving them to the Core Values. I have noted 1 area with yellow highlighting for follow-up: In the chapeau on page 3 we note the need to define confidentiality and non-disclosure rules when the review team accesses documents that ICANN management says are confidential, sensitive, or proprietary. —Steve From: Steve DelBianco Date: Friday, July 17, 2015 at 7:40 AM To: "accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>" Cc: Jordan Carter, Avri Doria, "wp1@icann.org<mailto:wp1@icann.org>" Subject: Bringing AoC Reviews into ICANN Bylaws, v4 reflecting Paris discussion Today (17-Jul) we reviewed and revised the proposal to bring AoC Reviews into the ICANN Bylaws. By my notes, here are the changes we agreed today: Preference for option 2 on team composition, so removed 3-May proposal and Option 1. Allow ATRT to amend these reviews, too. Add 1 ICANN board member to each review team under option 2. Note that our 3-May draft had a board member on each team. Bruce Tonkin suggested requiring review teams to Prioritize their recommendations. We heard several objections to making that a requirement, so I added it as a suggestion: "The review team should attempt to assign priorities to its recommendations." Remaining challenges: How to give review team access to ICANN Internal documents, while preventing disclosure/publication of information that is sensitive, confidential, or proprietary? Do we impose sanctions for unauthorized disclosure? HELP NEEDED HERE. Steve Crocker recommended changing the AoC commitments for WHOIS/Directory Services. We heard some agreement with that idea, but strong cautions about attempting to drop WHOIS commitments as part of the transition. Instead, amendments to the WHOIS/Directory Services review could be recommended by the first post-transition ATRT. — Steve DelBianco Executive Director NetChoice http://www.NetChoice.org<http://www.netchoice.org/> and http://blog.netchoice.org<http://blog.netchoice.org/> +1.703.615.6206
Since this is going into the bylaws, and because some personal data is covered by regulations, do we need to cite ICANN’s Privacy Policy as controlling in these instances? From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Steve DelBianco Sent: Thursday, July 23, 2015 9:34 AM To: wp1@icann.org; Accountability Cross Community Cc: ACCT-Staff Subject: Re: [CCWG-ACCT] Bringing AoC Reviews into ICANN Bylaws, v5.4 reflecting Paris and new Non-Disclosure rule Update to reflect discussions in WP1 yesterday, regarding the non-disclosure provision. CCWG is proposing giving AoC Review Teams access to ICANN internal documents, which includes some information that is proprietary or sensitive. This creates two disclosure concerns: First, what to do if ICANN redacts or withholds any information sought by a review team? Second, of information that is shared with the review team, how to determine which information the Review Team must not disclose — in its report or otherwise? A subset of WP1 members (Alan Greenberg, Greg Shatan, James Gannon, Jordan Carter, and me) drafted new text, shown below and on page 3 of the attached doc. Confidential Disclosure to Review Teams: To facilitate transparency and openness regarding ICANN's deliberations and operations, the review teams, or a subset thereof, shall have access to ICANN internal information and documents. If ICANN refuses to reveal documents or information requested by the review team, ICANN must provide a justification to the review team. If the review team is not satisfied with ICANN’s justification, it can appeal to the Ombudsman and/or the ICANN Board for a ruling on the disclosure request. For documents and information that ICANN does disclose to the review team, ICANN may designate certain documents and information as not for disclosure by the review team, either in its report or otherwise. If the review team is not satisfied with ICANN’s designation of non-disclosable documents or information, it can appeal to the Ombudsman and/or the ICANN Board for a ruling on the non-disclosure designation. A confidential disclosure framework shall be published by ICANN. The confidential disclosure framework shall describe the process by which documents and information is classified, including a description of the levels of classification that documents or information may be subject to, and the classes of persons who may access such documents and information The confidential disclosure framework shall describe the process by which a review team may request access to documents and information that are designated as classified or restricted access. The confidential disclosure framework must provide a mechanism to escalate and/or appeal the refusal to release documents and information to duly recognized review teams. From: Steve DelBianco Date: Monday, July 20, 2015 at 2:01 PM To: "wp1@icann.org<mailto:wp1@icann.org>" Cc: Jordan Carter, Avri Doria Subject: Bringing AoC Reviews into ICANN Bylaws, v5 reflecting Paris Saturday discussion Updated to reflect Saturday in Paris, where we said that commitments stated within the new gTLD and WHOIS reviews would stay in that section of the Bylaws, instead of moving them to the Core Values. I have noted 1 area with yellow highlighting for follow-up: In the chapeau on page 3 we note the need to define confidentiality and non-disclosure rules when the review team accesses documents that ICANN management says are confidential, sensitive, or proprietary. —Steve From: Steve DelBianco Date: Friday, July 17, 2015 at 7:40 AM To: "accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>" Cc: Jordan Carter, Avri Doria, "wp1@icann.org<mailto:wp1@icann.org>" Subject: Bringing AoC Reviews into ICANN Bylaws, v4 reflecting Paris discussion Today (17-Jul) we reviewed and revised the proposal to bring AoC Reviews into the ICANN Bylaws. By my notes, here are the changes we agreed today: Preference for option 2 on team composition, so removed 3-May proposal and Option 1. Allow ATRT to amend these reviews, too. Add 1 ICANN board member to each review team under option 2. Note that our 3-May draft had a board member on each team. Bruce Tonkin suggested requiring review teams to Prioritize their recommendations. We heard several objections to making that a requirement, so I added it as a suggestion: "The review team should attempt to assign priorities to its recommendations." Remaining challenges: How to give review team access to ICANN Internal documents, while preventing disclosure/publication of information that is sensitive, confidential, or proprietary? Do we impose sanctions for unauthorized disclosure? HELP NEEDED HERE. Steve Crocker recommended changing the AoC commitments for WHOIS/Directory Services. We heard some agreement with that idea, but strong cautions about attempting to drop WHOIS commitments as part of the transition. Instead, amendments to the WHOIS/Directory Services review could be recommended by the first post-transition ATRT. — Steve DelBianco Executive Director NetChoice http://www.NetChoice.org<http://www.netchoice.org/> and http://blog.netchoice.org<http://blog.netchoice.org/> +1.703.615.6206
The place to reflect that would be in the Confidential Disclosure Framework rather than in the bylaws in my opinion. -James From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Chartier, Mike S Sent: Thursday, July 23, 2015 3:16 PM To: Steve DelBianco; wp1@icann.org; Accountability Cross Community Cc: ACCT-Staff Subject: Re: [CCWG-ACCT] Bringing AoC Reviews into ICANN Bylaws, v5.4 reflecting Paris and new Non-Disclosure rule Since this is going into the bylaws, and because some personal data is covered by regulations, do we need to cite ICANN’s Privacy Policy as controlling in these instances? From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Steve DelBianco Sent: Thursday, July 23, 2015 9:34 AM To: wp1@icann.org<mailto:wp1@icann.org>; Accountability Cross Community Cc: ACCT-Staff Subject: Re: [CCWG-ACCT] Bringing AoC Reviews into ICANN Bylaws, v5.4 reflecting Paris and new Non-Disclosure rule Update to reflect discussions in WP1 yesterday, regarding the non-disclosure provision. CCWG is proposing giving AoC Review Teams access to ICANN internal documents, which includes some information that is proprietary or sensitive. This creates two disclosure concerns: First, what to do if ICANN redacts or withholds any information sought by a review team? Second, of information that is shared with the review team, how to determine which information the Review Team must not disclose — in its report or otherwise? A subset of WP1 members (Alan Greenberg, Greg Shatan, James Gannon, Jordan Carter, and me) drafted new text, shown below and on page 3 of the attached doc. Confidential Disclosure to Review Teams: To facilitate transparency and openness regarding ICANN's deliberations and operations, the review teams, or a subset thereof, shall have access to ICANN internal information and documents. If ICANN refuses to reveal documents or information requested by the review team, ICANN must provide a justification to the review team. If the review team is not satisfied with ICANN’s justification, it can appeal to the Ombudsman and/or the ICANN Board for a ruling on the disclosure request. For documents and information that ICANN does disclose to the review team, ICANN may designate certain documents and information as not for disclosure by the review team, either in its report or otherwise. If the review team is not satisfied with ICANN’s designation of non-disclosable documents or information, it can appeal to the Ombudsman and/or the ICANN Board for a ruling on the non-disclosure designation. A confidential disclosure framework shall be published by ICANN. The confidential disclosure framework shall describe the process by which documents and information is classified, including a description of the levels of classification that documents or information may be subject to, and the classes of persons who may access such documents and information The confidential disclosure framework shall describe the process by which a review team may request access to documents and information that are designated as classified or restricted access. The confidential disclosure framework must provide a mechanism to escalate and/or appeal the refusal to release documents and information to duly recognized review teams. From: Steve DelBianco Date: Monday, July 20, 2015 at 2:01 PM To: "wp1@icann.org<mailto:wp1@icann.org>" Cc: Jordan Carter, Avri Doria Subject: Bringing AoC Reviews into ICANN Bylaws, v5 reflecting Paris Saturday discussion Updated to reflect Saturday in Paris, where we said that commitments stated within the new gTLD and WHOIS reviews would stay in that section of the Bylaws, instead of moving them to the Core Values. I have noted 1 area with yellow highlighting for follow-up: In the chapeau on page 3 we note the need to define confidentiality and non-disclosure rules when the review team accesses documents that ICANN management says are confidential, sensitive, or proprietary. —Steve From: Steve DelBianco Date: Friday, July 17, 2015 at 7:40 AM To: "accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>" Cc: Jordan Carter, Avri Doria, "wp1@icann.org<mailto:wp1@icann.org>" Subject: Bringing AoC Reviews into ICANN Bylaws, v4 reflecting Paris discussion Today (17-Jul) we reviewed and revised the proposal to bring AoC Reviews into the ICANN Bylaws. By my notes, here are the changes we agreed today: Preference for option 2 on team composition, so removed 3-May proposal and Option 1. Allow ATRT to amend these reviews, too. Add 1 ICANN board member to each review team under option 2. Note that our 3-May draft had a board member on each team. Bruce Tonkin suggested requiring review teams to Prioritize their recommendations. We heard several objections to making that a requirement, so I added it as a suggestion: "The review team should attempt to assign priorities to its recommendations." Remaining challenges: How to give review team access to ICANN Internal documents, while preventing disclosure/publication of information that is sensitive, confidential, or proprietary? Do we impose sanctions for unauthorized disclosure? HELP NEEDED HERE. Steve Crocker recommended changing the AoC commitments for WHOIS/Directory Services. We heard some agreement with that idea, but strong cautions about attempting to drop WHOIS commitments as part of the transition. Instead, amendments to the WHOIS/Directory Services review could be recommended by the first post-transition ATRT. — Steve DelBianco Executive Director NetChoice http://www.NetChoice.org<http://www.netchoice.org/> and http://blog.netchoice.org<http://blog.netchoice.org/> +1.703.615.6206
Agree. Let's try to keep bylaw changes to a minimum. Thomas --- rickert.net
Am 23.07.2015 um 17:23 schrieb James Gannon <james@cyberinvasion.net>:
The place to reflect that would be in the Confidential Disclosure Framework rather than in the bylaws in my opinion.
-James
From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Chartier, Mike S Sent: Thursday, July 23, 2015 3:16 PM To: Steve DelBianco; wp1@icann.org; Accountability Cross Community Cc: ACCT-Staff Subject: Re: [CCWG-ACCT] Bringing AoC Reviews into ICANN Bylaws, v5.4 reflecting Paris and new Non-Disclosure rule
Since this is going into the bylaws, and because some personal data is covered by regulations, do we need to cite ICANN’s Privacy Policy as controlling in these instances?
From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Steve DelBianco Sent: Thursday, July 23, 2015 9:34 AM To: wp1@icann.org; Accountability Cross Community Cc: ACCT-Staff Subject: Re: [CCWG-ACCT] Bringing AoC Reviews into ICANN Bylaws, v5.4 reflecting Paris and new Non-Disclosure rule
Update to reflect discussions in WP1 yesterday, regarding the non-disclosure provision.
CCWG is proposing giving AoC Review Teams access to ICANN internal documents, which includes some information that is proprietary or sensitive. This creates two disclosure concerns:
First, what to do if ICANN redacts or withholds any information sought by a review team?
Second, of information that is shared with the review team, how to determine which information the Review Team must not disclose — in its report or otherwise?
A subset of WP1 members (Alan Greenberg, Greg Shatan, James Gannon, Jordan Carter, and me) drafted new text, shown below and on page 3 of the attached doc.
Confidential Disclosure to Review Teams: To facilitate transparency and openness regarding ICANN's deliberations and operations, the review teams, or a subset thereof, shall have access to ICANN internal information and documents. If ICANN refuses to reveal documents or information requested by the review team, ICANN must provide a justification to the review team. If the review team is not satisfied with ICANN’s justification, it can appeal to the Ombudsman and/or the ICANN Board for a ruling on the disclosure request.
For documents and information that ICANN does disclose to the review team, ICANN may designate certain documents and information as not for disclosure by the review team, either in its report or otherwise. If the review team is not satisfied with ICANN’s designation of non-disclosable documents or information, it can appeal to the Ombudsman and/or the ICANN Board for a ruling on the non-disclosure designation.
A confidential disclosure framework shall be published by ICANN. The confidential disclosure framework shall describe the process by which documents and information is classified, including a description of the levels of classification that documents or information may be subject to, and the classes of persons who may access such documents and information
The confidential disclosure framework shall describe the process by which a review team may request access to documents and information that are designated as classified or restricted access. The confidential disclosure framework must provide a mechanism to escalate and/or appeal the refusal to release documents and information to duly recognized review teams.
From: Steve DelBianco Date: Monday, July 20, 2015 at 2:01 PM To: "wp1@icann.org" Cc: Jordan Carter, Avri Doria Subject: Bringing AoC Reviews into ICANN Bylaws, v5 reflecting Paris Saturday discussion
Updated to reflect Saturday in Paris, where we said that commitments stated within the new gTLD and WHOIS reviews would stay in that section of the Bylaws, instead of moving them to the Core Values.
I have noted 1 area with yellow highlighting for follow-up:
In the chapeau on page 3 we note the need to define confidentiality and non-disclosure rules when the review team accesses documents that ICANN management says are confidential, sensitive, or proprietary.
—Steve
From: Steve DelBianco Date: Friday, July 17, 2015 at 7:40 AM To: "accountability-cross-community@icann.org" Cc: Jordan Carter, Avri Doria, "wp1@icann.org" Subject: Bringing AoC Reviews into ICANN Bylaws, v4 reflecting Paris discussion
Today (17-Jul) we reviewed and revised the proposal to bring AoC Reviews into the ICANN Bylaws.
By my notes, here are the changes we agreed today:
Preference for option 2 on team composition, so removed 3-May proposal and Option 1.
Allow ATRT to amend these reviews, too.
Add 1 ICANN board member to each review team under option 2. Note that our 3-May draft had a board member on each team.
Bruce Tonkin suggested requiring review teams to Prioritize their recommendations. We heard several objections to making that a requirement, so I added it as a suggestion: "The review team should attempt to assign priorities to its recommendations."
Remaining challenges:
How to give review team access to ICANN Internal documents, while preventing disclosure/publication of information that is sensitive, confidential, or proprietary? Do we impose sanctions for unauthorized disclosure? HELP NEEDED HERE.
Steve Crocker recommended changing the AoC commitments for WHOIS/Directory Services. We heard some agreement with that idea, but strong cautions about attempting to drop WHOIS commitments as part of the transition. Instead, amendments to the WHOIS/Directory Services review could be recommended by the first post-transition ATRT.
— Steve DelBianco Executive Director NetChoice http://www.NetChoice.org and http://blog.netchoice.org +1.703.615.6206
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Why? That's like saying let's keep legislative changes to the minumum. It MAY be appropriate, but it may not. It's not an end in itself. On 07/24/2015 07:44 AM, Thomas Rickert wrote:
.. Let's try to keep bylaw changes to a minimum.
Thomas
Hi Nigel, I agree, but I took Thomas' comment to mean, 'the fewest bylaws changes necessary to accomplish our goals.' I also agree with that, particularly for WS1. Regards, Keith
On Jul 24, 2015, at 9:55 AM, Nigel Roberts <nigel@channelisles.net> wrote:> Why?
That's like saying let's keep legislative changes to the minumum. It MAY be appropriate, but it may not.
It's not an end in itself.
On 07/24/2015 07:44 AM, Thomas Rickert wrote: .. Let's try to keep bylaw changes to a minimum.
Thomas
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Thanks Keith, you are correct. We should put in the bylaws what is required to achieve our goals. We should avoid putting redundant language in there as that may cause ambiguity. Not everything we need to accomplish needs to be put in the bylaws. We should only put into the bylaws what needs to be in the bylaws and put other areas into policies or other documents to abide by. Thomas --- rickert.net
Am 24.07.2015 um 09:07 schrieb Drazek, Keith <kdrazek@verisign.com>:
Hi Nigel,
I agree, but I took Thomas' comment to mean, 'the fewest bylaws changes necessary to accomplish our goals.' I also agree with that, particularly for WS1.
Regards, Keith
On Jul 24, 2015, at 9:55 AM, Nigel Roberts <nigel@channelisles.net> wrote:> Why?
That's like saying let's keep legislative changes to the minumum. It MAY be appropriate, but it may not.
It's not an end in itself.
On 07/24/2015 07:44 AM, Thomas Rickert wrote: .. Let's try to keep bylaw changes to a minimum.
Thomas
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Totally agree with you Thomas. The Bylaws should be lean, flexible and contain only what is absolutely necessary for ICANN to function as a responsive accountable membership based California public benefits corporation. Everything else should find a home in operations and procedural documentation. Sent from my iPhone
On Jul 24, 2015, at 12:11 PM, Thomas Rickert <rickert@anwaelte.de> wrote:
Thanks Keith, you are correct.
We should put in the bylaws what is required to achieve our goals. We should avoid putting redundant language in there as that may cause ambiguity. Not everything we need to accomplish needs to be put in the bylaws. We should only put into the bylaws what needs to be in the bylaws and put other areas into policies or other documents to abide by.
Thomas
--- rickert.net
Am 24.07.2015 um 09:07 schrieb Drazek, Keith <kdrazek@verisign.com>:
Hi Nigel,
I agree, but I took Thomas' comment to mean, 'the fewest bylaws changes necessary to accomplish our goals.' I also agree with that, particularly for WS1.
Regards, Keith
On Jul 24, 2015, at 9:55 AM, Nigel Roberts <nigel@channelisles.net> wrote:> Why?
That's like saying let's keep legislative changes to the minumum. It MAY be appropriate, but it may not.
It's not an end in itself.
On 07/24/2015 07:44 AM, Thomas Rickert wrote: .. Let's try to keep bylaw changes to a minimum.
Thomas
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
+1 Von meinem iPhone gesendet Am 24.07.2015 um 13:26 schrieb Edward Morris <egmorris1@toast.net<mailto:egmorris1@toast.net>>: Totally agree with you Thomas. The Bylaws should be lean, flexible and contain only what is absolutely necessary for ICANN to function as a responsive accountable membership based California public benefits corporation. Everything else should find a home in operations and procedural documentation. Sent from my iPhone On Jul 24, 2015, at 12:11 PM, Thomas Rickert <rickert@anwaelte.de<mailto:rickert@anwaelte.de>> wrote: Thanks Keith, you are correct. We should put in the bylaws what is required to achieve our goals. We should avoid putting redundant language in there as that may cause ambiguity. Not everything we need to accomplish needs to be put in the bylaws. We should only put into the bylaws what needs to be in the bylaws and put other areas into policies or other documents to abide by. Thomas --- rickert.net<http://rickert.net> Am 24.07.2015 um 09:07 schrieb Drazek, Keith <kdrazek@verisign.com<mailto:kdrazek@verisign.com>>: Hi Nigel, I agree, but I took Thomas' comment to mean, 'the fewest bylaws changes necessary to accomplish our goals.' I also agree with that, particularly for WS1. Regards, Keith On Jul 24, 2015, at 9:55 AM, Nigel Roberts <nigel@channelisles.net<mailto:nigel@channelisles.net>> wrote:> Why? That's like saying let's keep legislative changes to the minumum. It MAY be appropriate, but it may not. It's not an end in itself. On 07/24/2015 07:44 AM, Thomas Rickert wrote: .. Let's try to keep bylaw changes to a minimum. Thomas _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
I personally don't agree with the minimalist approach, though I agree with tring to avoid overreach. My view is more like: "Whatever it takes to get it right" And in the context of transparency it means full disclosure unless quite specifically permitted not to disclose. Not the other way around. el -- Sent from Dr Lisse's iPhone 6
On Jul 24, 2015, at 08:54, Nigel Roberts <nigel@channelisles.net> wrote:
Why?
That's like saying let's keep legislative changes to the minumum. It MAY be appropriate, but it may not.
It's not an end in itself.
On 07/24/2015 07:44 AM, Thomas Rickert wrote: .. Let's try to keep bylaw changes to a minimum.
Thomas
For all it is worth, there are people I trust, and if they read the "to be redacted" information I would most likely still trust them. That would however pre-suppose a more detailed definition of what can be redacted (not what must be disclosed) before the fact. I firmly believe that currently this is being abused. el -- Sent from Dr Lisse's iPhone 6
On Jul 24, 2015, at 07:44, Thomas Rickert <rickert@anwaelte.de> wrote:
Agree. Let's try to keep bylaw changes to a minimum.
Thomas
--- rickert.net
Am 23.07.2015 um 17:23 schrieb James Gannon <james@cyberinvasion.net>:
The place to reflect that would be in the Confidential Disclosure Framework rather than in the bylaws in my opinion.
-James
From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Chartier, Mike S Sent: Thursday, July 23, 2015 3:16 PM To: Steve DelBianco; wp1@icann.org; Accountability Cross Community Cc: ACCT-Staff Subject: Re: [CCWG-ACCT] Bringing AoC Reviews into ICANN Bylaws, v5.4 reflecting Paris and new Non-Disclosure rule
Since this is going into the bylaws, and because some personal data is covered by regulations, do we need to cite ICANN’s Privacy Policy as controlling in these instances?
From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Steve DelBianco Sent: Thursday, July 23, 2015 9:34 AM To: wp1@icann.org; Accountability Cross Community Cc: ACCT-Staff Subject: Re: [CCWG-ACCT] Bringing AoC Reviews into ICANN Bylaws, v5.4 reflecting Paris and new Non-Disclosure rule
Update to reflect discussions in WP1 yesterday, regarding the non-disclosure provision.
CCWG is proposing giving AoC Review Teams access to ICANN internal documents, which includes some information that is proprietary or sensitive. This creates two disclosure concerns:
First, what to do if ICANN redacts or withholds any information sought by a review team?
Second, of information that is shared with the review team, how to determine which information the Review Team must not disclose — in its report or otherwise?
A subset of WP1 members (Alan Greenberg, Greg Shatan, James Gannon, Jordan Carter, and me) drafted new text, shown below and on page 3 of the attached doc.
Confidential Disclosure to Review Teams: To facilitate transparency and openness regarding ICANN's deliberations and operations, the review teams, or a subset thereof, shall have access to ICANN internal information and documents. If ICANN refuses to reveal documents or information requested by the review team, ICANN must provide a justification to the review team. If the review team is not satisfied with ICANN’s justification, it can appeal to the Ombudsman and/or the ICANN Board for a ruling on the disclosure request.
For documents and information that ICANN does disclose to the review team, ICANN may designate certain documents and information as not for disclosure by the review team, either in its report or otherwise. If the review team is not satisfied with ICANN’s designation of non-disclosable documents or information, it can appeal to the Ombudsman and/or the ICANN Board for a ruling on the non-disclosure designation.
A confidential disclosure framework shall be published by ICANN. The confidential disclosure framework shall describe the process by which documents and information is classified, including a description of the levels of classification that documents or information may be subject to, and the classes of persons who may access such documents and information
The confidential disclosure framework shall describe the process by which a review team may request access to documents and information that are designated as classified or restricted access. The confidential disclosure framework must provide a mechanism to escalate and/or appeal the refusal to release documents and information to duly recognized review teams.
From: Steve DelBianco Date: Monday, July 20, 2015 at 2:01 PM To: "wp1@icann.org" Cc: Jordan Carter, Avri Doria Subject: Bringing AoC Reviews into ICANN Bylaws, v5 reflecting Paris Saturday discussion
Updated to reflect Saturday in Paris, where we said that commitments stated within the new gTLD and WHOIS reviews would stay in that section of the Bylaws, instead of moving them to the Core Values.
I have noted 1 area with yellow highlighting for follow-up:
In the chapeau on page 3 we note the need to define confidentiality and non-disclosure rules when the review team accesses documents that ICANN management says are confidential, sensitive, or proprietary.
—Steve
From: Steve DelBianco Date: Friday, July 17, 2015 at 7:40 AM To: "accountability-cross-community@icann.org" Cc: Jordan Carter, Avri Doria, "wp1@icann.org" Subject: Bringing AoC Reviews into ICANN Bylaws, v4 reflecting Paris discussion
Today (17-Jul) we reviewed and revised the proposal to bring AoC Reviews into the ICANN Bylaws.
By my notes, here are the changes we agreed today:
Preference for option 2 on team composition, so removed 3-May proposal and Option 1.
Allow ATRT to amend these reviews, too.
Add 1 ICANN board member to each review team under option 2. Note that our 3-May draft had a board member on each team.
Bruce Tonkin suggested requiring review teams to Prioritize their recommendations. We heard several objections to making that a requirement, so I added it as a suggestion: "The review team should attempt to assign priorities to its recommendations."
Remaining challenges:
How to give review team access to ICANN Internal documents, while preventing disclosure/publication of information that is sensitive, confidential, or proprietary? Do we impose sanctions for unauthorized disclosure? HELP NEEDED HERE.
Steve Crocker recommended changing the AoC commitments for WHOIS/Directory Services. We heard some agreement with that idea, but strong cautions about attempting to drop WHOIS commitments as part of the transition. Instead, amendments to the WHOIS/Directory Services review could be recommended by the first post-transition ATRT.
— Steve DelBianco Executive Director NetChoice http://www.NetChoice.org and http://blog.netchoice.org +1.703.615.6206
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
All, These are my personal opinions. I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing. When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences. So here's what I'd like to contribute ... I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain. In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be. The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity. If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway. I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control. In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it. The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me. In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it. Please consider these thoughts in your discussions. George
George, though I agree about right vs quick, if it only were so that we fundamentally redesigned ICANN. Which it needs. el -- Sent from Dr Lisse's iPad mini
On Jul 27, 2015, at 16:30, George Sadowsky <george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
What I think you're missing with your analysis, George, is the fact that the community knows it has a window to put things in place so more granular changes can be made later. The veto is the backstop to make those future changes happen. Without it, no one believes ICANN will actually make the required changes. After all, people have been asking for a decade now and only very slight improvements have emerged as a result. The veto is there to make sure ICANN can't weasel out of change once it has IANA. It is also a test of good faith on the Board's part. Is the Board actually willing to be held accountable or will it try to argue its way out of giving the community any real additional powers? Kieren On Mon, Jul 27, 2015 at 8:41 AM Dr Eberhard W Lisse <el@lisse.na> wrote:
George,
though I agree about right vs quick, if it only were so that we fundamentally redesigned ICANN.
Which it needs.
el
-- Sent from Dr Lisse's iPad mini
On Jul 27, 2015, at 16:30, George Sadowsky <george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
And fundamentally, this is an empowerment issue, not meant to be a practical tool for budget or strategic plan development. A big part of WS2 is improving the process by which the budget and strategic plan are developed in the first place. WS1 is about empowering the community. From: <accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org>> on behalf of Kieren McCarthy Date: Monday, July 27, 2015 at 1:00 PM To: Dr Eberhard W Lisse, CCWG Accountability Cc: "directors@omadhina.net<mailto:directors@omadhina.net>" Subject: Re: [CCWG-ACCT] Budgetary veto/control solves the wrong problem and avoids solving the right one What I think you're missing with your analysis, George, is the fact that the community knows it has a window to put things in place so more granular changes can be made later. The veto is the backstop to make those future changes happen. Without it, no one believes ICANN will actually make the required changes. After all, people have been asking for a decade now and only very slight improvements have emerged as a result. The veto is there to make sure ICANN can't weasel out of change once it has IANA. It is also a test of good faith on the Board's part. Is the Board actually willing to be held accountable or will it try to argue its way out of giving the community any real additional powers? Kieren On Mon, Jul 27, 2015 at 8:41 AM Dr Eberhard W Lisse <el@lisse.na<mailto:el@lisse.na>> wrote: George, though I agree about right vs quick, if it only were so that we fundamentally redesigned ICANN. Which it needs. el -- Sent from Dr Lisse's iPad mini
On Jul 27, 2015, at 16:30, George Sadowsky <george.sadowsky@gmail.com<mailto:george.sadowsky@gmail.com>> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
I'd go further in thanking you, George, for a nice write up of what WS2 needs to solve in these respects. But given the community's feedback on the WS1 proposal, dropping this power now isn't going to work. It is also worth me gently pointing out that we have to finalise our draft proposal in the next 36 hours or so. Going back to basics isn't viable. best Jordan On 28 July 2015 at 05:15, Jonathan Zuck <JZuck@actonline.org> wrote:
And fundamentally, this is an empowerment issue, not meant to be a practical tool for budget or strategic plan development. A big part of WS2 is improving the process by which the budget and strategic plan are developed in the first place. WS1 is about empowering the community.
From: <accountability-cross-community-bounces@icann.org> on behalf of Kieren McCarthy Date: Monday, July 27, 2015 at 1:00 PM To: Dr Eberhard W Lisse, CCWG Accountability Cc: "directors@omadhina.net" Subject: Re: [CCWG-ACCT] Budgetary veto/control solves the wrong problem and avoids solving the right one
What I think you're missing with your analysis, George, is the fact that the community knows it has a window to put things in place so more granular changes can be made later.
The veto is the backstop to make those future changes happen. Without it, no one believes ICANN will actually make the required changes. After all, people have been asking for a decade now and only very slight improvements have emerged as a result.
The veto is there to make sure ICANN can't weasel out of change once it has IANA.
It is also a test of good faith on the Board's part. Is the Board actually willing to be held accountable or will it try to argue its way out of giving the community any real additional powers?
Kieren On Mon, Jul 27, 2015 at 8:41 AM Dr Eberhard W Lisse <el@lisse.na> wrote:
George,
though I agree about right vs quick, if it only were so that we fundamentally redesigned ICANN.
Which it needs.
el
-- Sent from Dr Lisse's iPad mini
On Jul 27, 2015, at 16:30, George Sadowsky <george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Jordan Carter Chief Executive *InternetNZ* +64-495-2118 (office) | +64-21-442-649 (mob) Email: jordan@internetnz.net.nz Skype: jordancarter *A better world through a better Internet *
Jordan, CCWG-team - I mentioned in Paris that I would want ICANN's auditors to check whether they would expect any particular difficulties with a budget veto. We reached out to them and are waiting for their answers. I will keep you all informed about their feedback. Thanks for the extraordinary work you all are doing! Erika On Mon, Jul 27, 2015 at 8:46 PM, Jordan Carter <jordan@internetnz.net.nz> wrote:
I'd go further in thanking you, George, for a nice write up of what WS2 needs to solve in these respects.
But given the community's feedback on the WS1 proposal, dropping this power now isn't going to work.
It is also worth me gently pointing out that we have to finalise our draft proposal in the next 36 hours or so. Going back to basics isn't viable.
best Jordan
On 28 July 2015 at 05:15, Jonathan Zuck <JZuck@actonline.org> wrote:
And fundamentally, this is an empowerment issue, not meant to be a practical tool for budget or strategic plan development. A big part of WS2 is improving the process by which the budget and strategic plan are developed in the first place. WS1 is about empowering the community.
From: <accountability-cross-community-bounces@icann.org> on behalf of Kieren McCarthy Date: Monday, July 27, 2015 at 1:00 PM To: Dr Eberhard W Lisse, CCWG Accountability Cc: "directors@omadhina.net" Subject: Re: [CCWG-ACCT] Budgetary veto/control solves the wrong problem and avoids solving the right one
What I think you're missing with your analysis, George, is the fact that the community knows it has a window to put things in place so more granular changes can be made later.
The veto is the backstop to make those future changes happen. Without it, no one believes ICANN will actually make the required changes. After all, people have been asking for a decade now and only very slight improvements have emerged as a result.
The veto is there to make sure ICANN can't weasel out of change once it has IANA.
It is also a test of good faith on the Board's part. Is the Board actually willing to be held accountable or will it try to argue its way out of giving the community any real additional powers?
Kieren On Mon, Jul 27, 2015 at 8:41 AM Dr Eberhard W Lisse <el@lisse.na> wrote:
George,
though I agree about right vs quick, if it only were so that we fundamentally redesigned ICANN.
Which it needs.
el
-- Sent from Dr Lisse's iPad mini
On Jul 27, 2015, at 16:30, George Sadowsky <george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Jordan Carter
Chief Executive *InternetNZ*
+64-495-2118 (office) | +64-21-442-649 (mob) Email: jordan@internetnz.net.nz Skype: jordancarter
*A better world through a better Internet *
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Dear George, I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise it…) Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets. On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether). This would be in my view a much more effective system of so called “checks and balances” than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business. Best Carlos Raúl Gutiérrez _____________________ email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
I don't think the budget veto was ever intended to substitute for community participation in the budget process, rather it was intended to encourage it (in a sort of dark and foreboding way). There are already a number of ways in which the community in general, and SOs and ACs (and their component parts) participate in the budget process, and these have been improving over time. I'm not going to catalogue them here, but I should think it's readily available on the website or from Xavier Calvez's team. These should continue to be improved. One continuing shortcoming is that we are all still supplicants, beseeching ICANN finance for a little more pie. While this is true in private (and public) entities as well, the level of influence of the community is probably lower than it should be. As it is now, the community can register all of its needs, concerns, demands, objections, etc., and in the end there is nothing to make those anything more than "kind requests." The budget veto is a final backstop in the event of a budget that fundamentally is at odds with where it should be. The budget veto should not be viewed primarily as a power, as much as an admonishment, to add discipline the budget process. It should constrain the Board from delivering a "veto-able" budget. The best way to avoid that, of course, is communication with and due consideration of the need of the community throughout the process. One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit"). A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced. A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses. There may be a point when sitting on a pile of cash is not consistent with the entity's goals, but that can also be true of a for-profit corporation. It's entirely fair to talk about the numbers, but we should be careful not to bring in presumptions that don't exist. [Caveat: I'm not referring to charitable organizations, which are often referred to as non-profits as well.] Greg On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org> wrote:
Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise it…)
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called “checks and balances” than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
In direct answer to George's original post, I'm all in favor of focusing on the right question of improving the overall budget process and the role of the community in that process. We can discuss that in WS2, among other places. But I don't think that in any way precludes the discussion we have been having, or make this the "wrong" thing to have in any way. Greg On Tue, Jul 28, 2015 at 1:02 PM, Greg Shatan <gregshatanipc@gmail.com> wrote:
I don't think the budget veto was ever intended to substitute for community participation in the budget process, rather it was intended to encourage it (in a sort of dark and foreboding way). There are already a number of ways in which the community in general, and SOs and ACs (and their component parts) participate in the budget process, and these have been improving over time. I'm not going to catalogue them here, but I should think it's readily available on the website or from Xavier Calvez's team. These should continue to be improved. One continuing shortcoming is that we are all still supplicants, beseeching ICANN finance for a little more pie. While this is true in private (and public) entities as well, the level of influence of the community is probably lower than it should be. As it is now, the community can register all of its needs, concerns, demands, objections, etc., and in the end there is nothing to make those anything more than "kind requests."
The budget veto is a final backstop in the event of a budget that fundamentally is at odds with where it should be. The budget veto should not be viewed primarily as a power, as much as an admonishment, to add discipline the budget process. It should constrain the Board from delivering a "veto-able" budget. The best way to avoid that, of course, is communication with and due consideration of the need of the community throughout the process.
One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit"). A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced. A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses. There may be a point when sitting on a pile of cash is not consistent with the entity's goals, but that can also be true of a for-profit corporation. It's entirely fair to talk about the numbers, but we should be careful not to bring in presumptions that don't exist. [Caveat: I'm not referring to charitable organizations, which are often referred to as non-profits as well.]
Greg
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org> wrote:
Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise it…)
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called “checks and balances” than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg On 28 Jul 2015, at 11:02, Greg Shatan wrote:
One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit").
No problem with reserves, contingencies, etc. ICANN has to big ones of 80 million each. But still a problem with unrealistic income projections, and optimistic spending just because we have more money coming in tomorrow.
A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced.
A healthy finial balance is always in place under the assumptions as per above.
A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses.
agree. Two sets of reserves of $80million/each is quite alright
Greg
cheers Carlos Raul
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org> wrote:
Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise it…)
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called “checks and balances” than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Carlos, as a point of reference, ICANN has an investment policy in place (https://www.icann.org/resources/pages/investment-policy-2014-07-30-en) that is regularly reviewed by the ICANN Board, which includes principles on how funds held by ICANN are managed, as well as the size of the reserve fund. On 7/28/15, 10:13 AM, "accountability-cross-community-bounces@icann.org on behalf of Carlos Raúl Gutiérrez" <accountability-cross-community-bounces@icann.org on behalf of crg@isoc-cr.org> wrote:
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg On 28 Jul 2015, at 11:02, Greg Shatan wrote:
One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit").
No problem with reserves, contingencies, etc. ICANN has to big ones of 80 million each. But still a problem with unrealistic income projections, and optimistic spending just because we have more money coming in tomorrow.
A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced.
A healthy finial balance is always in place under the assumptions as per above.
A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses.
agree. Two sets of reserves of $80million/each is quite alright
Greg
cheers Carlos Raul
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org> wrote:
Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise itŠ)
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called ³checks and balances² than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Thank you Samantha! Xavier was very clear on the Reserve funds strategies during his last presentation to the GNSO Council in Buenos Aires and I praise him for that. I don´t consider creating those reserve funds outside the good practices of Non-for-Profit corporations, like Greg Shatan tried to imply in his reply. Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg On 28 Jul 2015, at 13:20, Samantha Eisner wrote:
Carlos, as a point of reference, ICANN has an investment policy in place (https://www.icann.org/resources/pages/investment-policy-2014-07-30-en) that is regularly reviewed by the ICANN Board, which includes principles on how funds held by ICANN are managed, as well as the size of the reserve fund.
On 7/28/15, 10:13 AM, "accountability-cross-community-bounces@icann.org on behalf of Carlos Raúl Gutiérrez" <accountability-cross-community-bounces@icann.org on behalf of crg@isoc-cr.org> wrote:
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg On 28 Jul 2015, at 11:02, Greg Shatan wrote:
One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit").
No problem with reserves, contingencies, etc. ICANN has to big ones of 80 million each. But still a problem with unrealistic income projections, and optimistic spending just because we have more money coming in tomorrow.
A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced.
A healthy finial balance is always in place under the assumptions as per above.
A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses.
agree. Two sets of reserves of $80million/each is quite alright
Greg
cheers Carlos Raul
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org> wrote:
Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise itŠ)
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called ³checks and balances² than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Carlos, I read what you said originally ("financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit") as being based on the incorrect idea that a non-profit can't have a profit (a common misunderstanding). Clearly, that's not what you were saying, and you understand that "non-profit" is not quite so literal a term. Sorry I misunderstood you. Greg On Tue, Jul 28, 2015 at 4:45 PM, Carlos Raúl Gutiérrez <crg@isoc-cr.org> wrote:
Thank you Samantha!
Xavier was very clear on the Reserve funds strategies during his last presentation to the GNSO Council in Buenos Aires and I praise him for that. I don´t consider creating those reserve funds outside the good practices of Non-for-Profit corporations, like Greg Shatan tried to imply in his reply.
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg On 28 Jul 2015, at 13:20, Samantha Eisner wrote:
Carlos, as a point of reference, ICANN has an investment policy in place
(https://www.icann.org/resources/pages/investment-policy-2014-07-30-en) that is regularly reviewed by the ICANN Board, which includes principles on how funds held by ICANN are managed, as well as the size of the reserve fund.
On 7/28/15, 10:13 AM, "accountability-cross-community-bounces@icann.org on behalf of Carlos Raúl Gutiérrez" <accountability-cross-community-bounces@icann.org on behalf of crg@isoc-cr.org> wrote:
Carlos Raúl Gutiérrez +506 8837 7176
Skype: carlos.raulg On 28 Jul 2015, at 11:02, Greg Shatan wrote:
One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit").
No problem with reserves, contingencies, etc. ICANN has to big ones of 80 million each. But still a problem with unrealistic income projections, and optimistic spending just because we have more money coming in tomorrow.
A
"for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced.
A healthy finial balance is always in place under the assumptions as per above.
A non-profit, like a for-profit, needs to balance
its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses.
agree. Two sets of reserves of $80million/each is quite alright
Greg
cheers Carlos Raul
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org> wrote:
Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise itŠ)
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called ³checks and balances² than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com>
wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
No prob Greg! I truly believe Budget should remain in WS2 in any case as you proposed. We need to delve much deeper into the financial aspects of all this. cheers Carlos Raúl Gutiérrez _____________________ email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 28, 2015, at 2:51 PM, Greg Shatan <gregshatanipc@gmail.com> wrote:
Carlos,
I read what you said originally ("financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit") as being based on the incorrect idea that a non-profit can't have a profit (a common misunderstanding). Clearly, that's not what you were saying, and you understand that "non-profit" is not quite so literal a term. Sorry I misunderstood you.
Greg
On Tue, Jul 28, 2015 at 4:45 PM, Carlos Raúl Gutiérrez <crg@isoc-cr.org <mailto:crg@isoc-cr.org>> wrote: Thank you Samantha!
Xavier was very clear on the Reserve funds strategies during his last presentation to the GNSO Council in Buenos Aires and I praise him for that. I don´t consider creating those reserve funds outside the good practices of Non-for-Profit corporations, like Greg Shatan tried to imply in his reply.
Carlos Raúl Gutiérrez +506 8837 7176 <tel:%2B506%208837%207176> Skype: carlos.raulg On 28 Jul 2015, at 13:20, Samantha Eisner wrote:
Carlos, as a point of reference, ICANN has an investment policy in place (https://www.icann.org/resources/pages/investment-policy-2014-07-30-en <https://www.icann.org/resources/pages/investment-policy-2014-07-30-en>) that is regularly reviewed by the ICANN Board, which includes principles on how funds held by ICANN are managed, as well as the size of the reserve fund.
On 7/28/15, 10:13 AM, "accountability-cross-community-bounces@icann.org <mailto:accountability-cross-community-bounces@icann.org> on behalf of Carlos Raúl Gutiérrez" <accountability-cross-community-bounces@icann.org <mailto:accountability-cross-community-bounces@icann.org> on behalf of crg@isoc-cr.org <mailto:crg@isoc-cr.org>> wrote:
Carlos Raúl Gutiérrez +506 8837 7176 <tel:%2B506%208837%207176>
Skype: carlos.raulg On 28 Jul 2015, at 11:02, Greg Shatan wrote: One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit").
No problem with reserves, contingencies, etc. ICANN has to big ones of 80 million each. But still a problem with unrealistic income projections, and optimistic spending just because we have more money coming in tomorrow.
A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced.
A healthy finial balance is always in place under the assumptions as per above.
A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses.
agree. Two sets of reserves of $80million/each is quite alright
Greg
cheers Carlos Raul
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org <mailto:crg@isoc-cr.org>> wrote:
Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise itŠ)
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called ³checks and balances² than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org <mailto:crg@isoc-cr.org> Skype: carlos.raulg +506 8837 7173 <tel:%2B506%208837%207173> (cel) +506 4000 2000 <tel:%2B506%204000%202000> (home) +506 2290 3678 <tel:%2B506%202290%203678> (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com <mailto:george.sadowsky@gmail.com>>
wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
Great! Glad we are back on the same page. Best regards, Greg On Tue, Jul 28, 2015 at 4:53 PM, Carlos Raúl Gutiérrez <crg@isoc-cr.org> wrote:
No prob Greg!
I truly believe Budget should remain in WS2 in any case as you proposed. We need to delve much deeper into the financial aspects of all this.
cheers
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 28, 2015, at 2:51 PM, Greg Shatan <gregshatanipc@gmail.com> wrote:
Carlos,
I read what you said originally ("financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit") as being based on the incorrect idea that a non-profit can't have a profit (a common misunderstanding). Clearly, that's not what you were saying, and you understand that "non-profit" is not quite so literal a term. Sorry I misunderstood you.
Greg
On Tue, Jul 28, 2015 at 4:45 PM, Carlos Raúl Gutiérrez <crg@isoc-cr.org> wrote:
Thank you Samantha!
Xavier was very clear on the Reserve funds strategies during his last presentation to the GNSO Council in Buenos Aires and I praise him for that. I don´t consider creating those reserve funds outside the good practices of Non-for-Profit corporations, like Greg Shatan tried to imply in his reply.
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg On 28 Jul 2015, at 13:20, Samantha Eisner wrote:
Carlos, as a point of reference, ICANN has an investment policy in place
(https://www.icann.org/resources/pages/investment-policy-2014-07-30-en) that is regularly reviewed by the ICANN Board, which includes principles on how funds held by ICANN are managed, as well as the size of the reserve fund.
On 7/28/15, 10:13 AM, "accountability-cross-community-bounces@icann.org on behalf of Carlos Raúl Gutiérrez" <accountability-cross-community-bounces@icann.org on behalf of crg@isoc-cr.org> wrote:
Carlos Raúl Gutiérrez +506 8837 7176
Skype: carlos.raulg On 28 Jul 2015, at 11:02, Greg Shatan wrote:
One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit").
No problem with reserves, contingencies, etc. ICANN has to big ones of 80 million each. But still a problem with unrealistic income projections, and optimistic spending just because we have more money coming in tomorrow.
A
"for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced.
A healthy finial balance is always in place under the assumptions as per above.
A non-profit, like a for-profit, needs to balance
its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses.
agree. Two sets of reserves of $80million/each is quite alright
Greg
cheers Carlos Raul
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org> wrote:
Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise itŠ)
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called ³checks and balances² than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com>
wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Greg: If that is really what you think, then it is high time ICANN was converted into a charity. That philosophy leads to open season for such as the application fees for new gTLDs and for the auctions. No. With one mail to the List you have done more damage to ICANN than anything else I can recall. Please withdraw it. CW PS: The question of reserves and al prudent surplus is entirely distinct from your implication that a not-for-profit is unconstrained as to its financial practices, the public interest notwithstanding. On 28 Jul 2015, at 19:02, Greg Shatan <gregshatanipc@gmail.com> wrote:
I don't think the budget veto was ever intended to substitute for community participation in the budget process, rather it was intended to encourage it (in a sort of dark and foreboding way). There are already a number of ways in which the community in general, and SOs and ACs (and their component parts) participate in the budget process, and these have been improving over time. I'm not going to catalogue them here, but I should think it's readily available on the website or from Xavier Calvez's team. These should continue to be improved. One continuing shortcoming is that we are all still supplicants, beseeching ICANN finance for a little more pie. While this is true in private (and public) entities as well, the level of influence of the community is probably lower than it should be. As it is now, the community can register all of its needs, concerns, demands, objections, etc., and in the end there is nothing to make those anything more than "kind requests."
The budget veto is a final backstop in the event of a budget that fundamentally is at odds with where it should be. The budget veto should not be viewed primarily as a power, as much as an admonishment, to add discipline the budget process. It should constrain the Board from delivering a "veto-able" budget. The best way to avoid that, of course, is communication with and due consideration of the need of the community throughout the process.
One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit"). A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced. A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses. There may be a point when sitting on a pile of cash is not consistent with the entity's goals, but that can also be true of a for-profit corporation. It's entirely fair to talk about the numbers, but we should be careful not to bring in presumptions that don't exist. [Caveat: I'm not referring to charitable organizations, which are often referred to as non-profits as well.]
Greg
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org> wrote: Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise it…)
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called “checks and balances” than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
It's called showing true colors... el -- Sent from Dr Lisse's iPad mini
On Jul 28, 2015, at 18:36, CW Mail <mail@christopherwilkinson.eu> wrote:
Greg:
If that is really what you think, then it is high time ICANN was converted into a charity.
That philosophy leads to open season for such as the application fees for new gTLDs and for the auctions.
No. With one mail to the List you have done more damage to ICANN than anything else I can recall.
Please withdraw it.
CW
PS: The question of reserves and al prudent surplus is entirely distinct from your implication that a not-for-profit is unconstrained as to its financial practices, the public interest notwithstanding.
On 28 Jul 2015, at 19:02, Greg Shatan <gregshatanipc@gmail.com> wrote:
I don't think the budget veto was ever intended to substitute for community participation in the budget process, rather it was intended to encourage it (in a sort of dark and foreboding way). There are already a number of ways in which the community in general, and SOs and ACs (and their component parts) participate in the budget process, and these have been improving over time. I'm not going to catalogue them here, but I should think it's readily available on the website or from Xavier Calvez's team. These should continue to be improved. One continuing shortcoming is that we are all still supplicants, beseeching ICANN finance for a little more pie. While this is true in private (and public) entities as well, the level of influence of the community is probably lower than it should be. As it is now, the community can register all of its needs, concerns, demands, objections, etc., and in the end there is nothing to make those anything more than "kind requests."
The budget veto is a final backstop in the event of a budget that fundamentally is at odds with where it should be. The budget veto should not be viewed primarily as a power, as much as an admonishment, to add discipline the budget process. It should constrain the Board from delivering a "veto-able" budget. The best way to avoid that, of course, is communication with and due consideration of the need of the community throughout the process.
One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit"). A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced. A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses. There may be a point when sitting on a pile of cash is not consistent with the entity's goals, but that can also be true of a for-profit corporation. It's entirely fair to talk about the numbers, but we should be careful not to bring in presumptions that don't exist. [Caveat: I'm not referring to charitable organizations, which are often referred to as non-profits as well.]
Greg
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org> wrote: Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise it…)
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called “checks and balances” than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Chris, You have clearly misunderstood my email rather phenomenally, which has you charging about and making extreme statements that have no basis in reality. There was no expression of a "philosophy." My statements were general in nature, factually accurate, and were not made about ICANN in particular. I was merely making the point that "non-profit" has a more narrow meaning than people often assume. There is a common misconception that "non-profit" literally means that the entity should strive to avoid any kind of profit or surplus and that it is violating its status if its revenues exceed its expenses. This is just not true. Non-profit does not mean that the corporation should "not" have a "profit." Non-profits can have a surplus of revenues over expenses, while still being entirely "non-profit." A "for-profit" distributes its surplus (net profits) to owners/shareholders. A non-profit does not. That's all I was saying -- no more and no less. I have no idea where you see a "philosophy" that leads to an "open season for such as the application fees for new gTLDs and for the auctions." I made no statement, express or implied, that a "not-for-profit is unconstrained as to its financial practices." These are gross mischaracterizations, with no basis in my email For the record, that's not my view at all. I said absolutely nothing that would advocate or form a basis for absolving ICANN of its obligations to act in the public interest, to act prudently in its financial practices, to use its surplus (as with all of its revenues) consistently with its mission, or to do each and every other thing that a "non-profit" corporation must do. This is your invention. Your statement "With one mail to the List you have done more damage to ICANN than anything else I can recall" would be extraordinarily offensive if it were not so completely absurd. I have deleted my more colorful thoughts about that statement and your email in general, which took great restraint. I trust that I have now set your wildly racing heart at ease. GS On Tue, Jul 28, 2015 at 1:36 PM, CW Mail <mail@christopherwilkinson.eu> wrote:
Greg:
If that is really what you think, then it is high time ICANN was converted into a charity.
That philosophy leads to open season for such as the application fees for new gTLDs and for the auctions.
No. With one mail to the List you have done more damage to ICANN than anything else I can recall.
Please withdraw it.
CW
PS: The question of reserves and al prudent surplus is entirely distinct from your implication that a not-for-profit is unconstrained as to its financial practices, the public interest notwithstanding.
On 28 Jul 2015, at 19:02, Greg Shatan <gregshatanipc@gmail.com> wrote:
I don't think the budget veto was ever intended to substitute for community participation in the budget process, rather it was intended to encourage it (in a sort of dark and foreboding way). There are already a number of ways in which the community in general, and SOs and ACs (and their component parts) participate in the budget process, and these have been improving over time. I'm not going to catalogue them here, but I should think it's readily available on the website or from Xavier Calvez's team. These should continue to be improved. One continuing shortcoming is that we are all still supplicants, beseeching ICANN finance for a little more pie. While this is true in private (and public) entities as well, the level of influence of the community is probably lower than it should be. As it is now, the community can register all of its needs, concerns, demands, objections, etc., and in the end there is nothing to make those anything more than "kind requests."
The budget veto is a final backstop in the event of a budget that fundamentally is at odds with where it should be. The budget veto should not be viewed primarily as a power, as much as an admonishment, to add discipline the budget process. It should constrain the Board from delivering a "veto-able" budget. The best way to avoid that, of course, is communication with and due consideration of the need of the community throughout the process.
One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit"). A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced. A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses. There may be a point when sitting on a pile of cash is not consistent with the entity's goals, but that can also be true of a for-profit corporation. It's entirely fair to talk about the numbers, but we should be careful not to bring in presumptions that don't exist. [Caveat: I'm not referring to charitable organizations, which are often referred to as non-profits as well.]
Greg
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org> wrote:
Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise it…)
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called “checks and balances” than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Hi Greg, I am not, by this note, speaking against the budget veto power per se. I am still undecided. I think your note in response to George helps to highlight the issue George has raised.
One continuing shortcoming is that we are all still supplicants, beseeching ICANN finance for a little more pie. While this is true in private (and public) entities as well, the level of influence of the community is probably lower than it should be. As it is now, the community can register all of its needs, concerns, demands, objections, etc., and in the end there is nothing to make those anything more than "kind requests.”
OK…but it is extraordinarily rare for ‘the community’ to have such a request. What actually happens is that individual parts of the community have a series of individual requests. I’m unclear how the budget veto helps with those in any way. It may help if there is a line item included that most of ‘the community’ don’t want but even that is problematic IMO. Let’s assume that the single member has a total of 20 votes (5 each for ASO, ccNSO, GNSO and ALAC) and that the threshold for the veto is 75%. That means that 15 votes are required. Let’s assume that ALAC asks for an allocation of $2,000,000 to run an At Large Summit. At the moment, that is an extraordinary item (i.e. it is not automatically budgeted for each year or each X years) and the process of approval involves, in essence, the Board approving it. Under the veto provision, it would be possible for the ASO, ccNSO and GNSO to vote against the budget because of that line item. Equally, the ALAC, ccNSO and ASO could vote against a gTLD industry summit line item or a non-commercial users meeting cost. And, entirely the reverse could happen with SOs and ACs 'horse-trading' with each other so that they each get their (to quote you) needs, concerns, demands, objections met. Is this really what we want to set up? Cheers, Chris
On 29 Jul 2015, at 03:02 , Greg Shatan <gregshatanipc@gmail.com> wrote:
I don't think the budget veto was ever intended to substitute for community participation in the budget process, rather it was intended to encourage it (in a sort of dark and foreboding way). There are already a number of ways in which the community in general, and SOs and ACs (and their component parts) participate in the budget process, and these have been improving over time. I'm not going to catalogue them here, but I should think it's readily available on the website or from Xavier Calvez's team. These should continue to be improved. One continuing shortcoming is that we are all still supplicants, beseeching ICANN finance for a little more pie. While this is true in private (and public) entities as well, the level of influence of the community is probably lower than it should be. As it is now, the community can register all of its needs, concerns, demands, objections, etc., and in the end there is nothing to make those anything more than "kind requests."
The budget veto is a final backstop in the event of a budget that fundamentally is at odds with where it should be. The budget veto should not be viewed primarily as a power, as much as an admonishment, to add discipline the budget process. It should constrain the Board from delivering a "veto-able" budget. The best way to avoid that, of course, is communication with and due consideration of the need of the community throughout the process.
One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit"). A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced. A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses. There may be a point when sitting on a pile of cash is not consistent with the entity's goals, but that can also be true of a for-profit corporation. It's entirely fair to talk about the numbers, but we should be careful not to bring in presumptions that don't exist. [Caveat: I'm not referring to charitable organizations, which are often referred to as non-profits as well.]
Greg
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org <mailto:crg@isoc-cr.org>> wrote: Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise it…)
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called “checks and balances” than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org <mailto:crg@isoc-cr.org> Skype: carlos.raulg +506 8837 7173 <tel:%2B506%208837%207173> (cel) +506 4000 2000 <tel:%2B506%204000%202000> (home) +506 2290 3678 <tel:%2B506%202290%203678> (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com <mailto:george.sadowsky@gmail.com>> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
On 29 Jul 2015 5:51 am, "Chris Disspain" <ceo@auda.org.au> wrote:.
Let’s assume that the single member has a total of 20 votes (5 each for
ASO, ccNSO, GNSO and ALAC) and that the threshold for the veto is 75%. That means that 15 votes are required.
SO: My understanding was that the 75% is from each SO/AC(i.e ~4 out of 5 votes of each SO/ALAC) and not from total votes casted
Let’s assume that ALAC asks for an allocation of $2,000,000 to run an At Large Summit. At the moment, that is an extraordinary item (i.e. it is not automatically budgeted for each year or each X years) and the process of approval involves, in essence, the Board approving it. Under the veto provision, it would be possible for the ASO, ccNSO and GNSO to vote against the budget because of that line item.
Equally, the ALAC, ccNSO and ASO could vote against a gTLD industry summit line item or a non-commercial users meeting cost. And, entirely the reverse could happen with SOs and ACs 'horse-trading' with each other so that they each get their (to quote you) needs, concerns, demands, objections met.
Is this really what we want to set up?
SO: If my understanding of the 75% above is incorrect then I agree as well; it's definitely not a setup to uphold. Regards
Cheers,
Chris
On 29 Jul 2015, at 03:02 , Greg Shatan <gregshatanipc@gmail.com> wrote:
I don't think the budget veto was ever intended to substitute for
community participation in the budget process, rather it was intended to encourage it (in a sort of dark and foreboding way). There are already a number of ways in which the community in general, and SOs and ACs (and their component parts) participate in the budget process, and these have been improving over time. I'm not going to catalogue them here, but I should think it's readily available on the website or from Xavier Calvez's team. These should continue to be improved. One continuing shortcoming is that we are all still supplicants, beseeching ICANN finance for a little more pie. While this is true in private (and public) entities as well, the level of influence of the community is probably lower than it should be. As it is now, the community can register all of its needs, concerns, demands, objections, etc., and in the end there is nothing to make those anything more than "kind requests."
The budget veto is a final backstop in the event of a budget that
fundamentally is at odds with where it should be. The budget veto should not be viewed primarily as a power, as much as an admonishment, to add discipline the budget process. It should constrain the Board from delivering a "veto-able" budget. The best way to avoid that, of course, is communication with and due consideration of the need of the community throughout the process.
One other note -- there seems to be a misunderstanding of what a
"non-profit corporation" (and why it is called "non-profit"). A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced. A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses. There may be a point when sitting on a pile of cash is not consistent with the entity's goals, but that can also be true of a for-profit corporation. It's entirely fair to talk about the numbers, but we should be careful not to bring in presumptions that don't exist. [Caveat: I'm not referring to charitable organizations, which are often referred to as non-profits as well.]
Greg
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org>
wrote:
Dear George,
I agree with you that a cumulated budget veto is a pretty useless
accountability tool (independently of how difficult it would be for the sole member to exercise it…)
Moreover, I think the community on the one hand should take care that
the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial
BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called
“checks and balances” than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com>
wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past
this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was
more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto
since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to
control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be
by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be
accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our
fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we
don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO
based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget
approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
SO: My understanding was that the 75% is from each SO/AC(i.e ~4 out of 5 votes of each SO/ALAC) and not from total votes casted
A good point and if I have misunderstood then I apologise. Could someone clarify please? Cheers, Chris
On 29 Jul 2015, at 15:45 , Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
On 29 Jul 2015 5:51 am, "Chris Disspain" <ceo@auda.org.au <mailto:ceo@auda.org.au>> wrote:.
Let’s assume that the single member has a total of 20 votes (5 each for ASO, ccNSO, GNSO and ALAC) and that the threshold for the veto is 75%. That means that 15 votes are required.
SO: My understanding was that the 75% is from each SO/AC(i.e ~4 out of 5 votes of each SO/ALAC) and not from total votes casted
Let’s assume that ALAC asks for an allocation of $2,000,000 to run an At Large Summit. At the moment, that is an extraordinary item (i.e. it is not automatically budgeted for each year or each X years) and the process of approval involves, in essence, the Board approving it. Under the veto provision, it would be possible for the ASO, ccNSO and GNSO to vote against the budget because of that line item.
Equally, the ALAC, ccNSO and ASO could vote against a gTLD industry summit line item or a non-commercial users meeting cost. And, entirely the reverse could happen with SOs and ACs 'horse-trading' with each other so that they each get their (to quote you) needs, concerns, demands, objections met.
Is this really what we want to set up?
SO: If my understanding of the 75% above is incorrect then I agree as well; it's definitely not a setup to uphold.
Regards
Cheers,
Chris
On 29 Jul 2015, at 03:02 , Greg Shatan <gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com>> wrote:
I don't think the budget veto was ever intended to substitute for community participation in the budget process, rather it was intended to encourage it (in a sort of dark and foreboding way). There are already a number of ways in which the community in general, and SOs and ACs (and their component parts) participate in the budget process, and these have been improving over time. I'm not going to catalogue them here, but I should think it's readily available on the website or from Xavier Calvez's team. These should continue to be improved. One continuing shortcoming is that we are all still supplicants, beseeching ICANN finance for a little more pie. While this is true in private (and public) entities as well, the level of influence of the community is probably lower than it should be. As it is now, the community can register all of its needs, concerns, demands, objections, etc., and in the end there is nothing to make those anything more than "kind requests."
The budget veto is a final backstop in the event of a budget that fundamentally is at odds with where it should be. The budget veto should not be viewed primarily as a power, as much as an admonishment, to add discipline the budget process. It should constrain the Board from delivering a "veto-able" budget. The best way to avoid that, of course, is communication with and due consideration of the need of the community throughout the process.
One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit"). A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced. A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses. There may be a point when sitting on a pile of cash is not consistent with the entity's goals, but that can also be true of a for-profit corporation. It's entirely fair to talk about the numbers, but we should be careful not to bring in presumptions that don't exist. [Caveat: I'm not referring to charitable organizations, which are often referred to as non-profits as well.]
Greg
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org <mailto:crg@isoc-cr.org>> wrote:
Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise it…)
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called “checks and balances” than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org <mailto:crg@isoc-cr.org> Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com <mailto:george.sadowsky@gmail.com>> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
Chris: you are right and Seun is wrong. We are not setting up mini-quorums or mini-vetoes by creating individual thresholds within participating SOs or ACs. best Jordan On 29 July 2015 at 17:48, Chris Disspain <ceo@auda.org.au> wrote:
SO: My understanding was that the 75% is from each SO/AC(i.e ~4 out of 5 votes of each SO/ALAC) and not from total votes casted
A good point and if I have misunderstood then I apologise. Could someone clarify please?
Cheers,
Chris
On 29 Jul 2015, at 15:45 , Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
On 29 Jul 2015 5:51 am, "Chris Disspain" <ceo@auda.org.au> wrote:.
Let’s assume that the single member has a total of 20 votes (5 each for
ASO, ccNSO, GNSO and ALAC) and that the threshold for the veto is 75%. That means that 15 votes are required.
SO: My understanding was that the 75% is from each SO/AC(i.e ~4 out of 5 votes of each SO/ALAC) and not from total votes casted
Let’s assume that ALAC asks for an allocation of $2,000,000 to run an At Large Summit. At the moment, that is an extraordinary item (i.e. it is not automatically budgeted for each year or each X years) and the process of approval involves, in essence, the Board approving it. Under the veto provision, it would be possible for the ASO, ccNSO and GNSO to vote against the budget because of that line item.
Equally, the ALAC, ccNSO and ASO could vote against a gTLD industry summit line item or a non-commercial users meeting cost. And, entirely the reverse could happen with SOs and ACs 'horse-trading' with each other so that they each get their (to quote you) needs, concerns, demands, objections met.
Is this really what we want to set up?
SO: If my understanding of the 75% above is incorrect then I agree as well; it's definitely not a setup to uphold.
Regards
Cheers,
Chris
On 29 Jul 2015, at 03:02 , Greg Shatan <gregshatanipc@gmail.com> wrote:
I don't think the budget veto was ever intended to substitute for
community participation in the budget process, rather it was intended to encourage it (in a sort of dark and foreboding way). There are already a number of ways in which the community in general, and SOs and ACs (and their component parts) participate in the budget process, and these have been improving over time. I'm not going to catalogue them here, but I should think it's readily available on the website or from Xavier Calvez's team. These should continue to be improved. One continuing shortcoming is that we are all still supplicants, beseeching ICANN finance for a little more pie. While this is true in private (and public) entities as well, the level of influence of the community is probably lower than it should be. As it is now, the community can register all of its needs, concerns, demands, objections, etc., and in the end there is nothing to make those anything more than "kind requests."
The budget veto is a final backstop in the event of a budget that
fundamentally is at odds with where it should be. The budget veto should not be viewed primarily as a power, as much as an admonishment, to add discipline the budget process. It should constrain the Board from delivering a "veto-able" budget. The best way to avoid that, of course, is communication with and due consideration of the need of the community throughout the process.
One other note -- there seems to be a misunderstanding of what a
"non-profit corporation" (and why it is called "non-profit"). A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced. A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses. There may be a point when sitting on a pile of cash is not consistent with the entity's goals, but that can also be true of a for-profit corporation. It's entirely fair to talk about the numbers, but we should be careful not to bring in presumptions that don't exist. [Caveat: I'm not referring to charitable organizations, which are often referred to as non-profits as well.]
Greg
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <
crg@isoc-cr.org> wrote:
Dear George,
I agree with you that a cumulated budget veto is a pretty useless
accountability tool (independently of how difficult it would be for the sole member to exercise it…)
Moreover, I think the community on the one hand should take care that
the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial
BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called
“checks and balances” than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <
george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past
this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was
more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto
since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to
control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be
by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be
accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our
fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we
don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is
IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget
approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Jordan Carter Chief Executive *InternetNZ* +64-495-2118 (office) | +64-21-442-649 (mob) Email: jordan@internetnz.net.nz Skype: jordancarter *A better world through a better Internet *
Hi Jordan, Okay thanks for marking the script. I guess Chris concern is valid then and I like to add my +1 to it. We will most likely be creating political parties within the SO/AC if that is implemented. There are three options that comes to mind to avoid this: - Define scope of what can be vetoed in a budget; it has to be items that are global to the community and not specific to SO/AC like the ALAC assembly is specific and as such should have the immunity - Put a minimal votes required from each SO/AC as an additional requirement to the 75% total - Determine that budget veto could cause more damage than it could fix and remove it as one of the possible powers. That said, I don't understand why it's the 75% of total when we all know that the budget veto power will be exercised by the "sole member" which comprises of all SO/AC. It just doesn't put the essence of sole membership in practice. Regards On 29 Jul 2015 7:01 am, "Jordan Carter" <jordan@internetnz.net.nz> wrote:
Chris: you are right and Seun is wrong. We are not setting up mini-quorums or mini-vetoes by creating individual thresholds within participating SOs or ACs.
best Jordan
On 29 July 2015 at 17:48, Chris Disspain <ceo@auda.org.au> wrote:
SO: My understanding was that the 75% is from each SO/AC(i.e ~4 out of 5 votes of each SO/ALAC) and not from total votes casted
A good point and if I have misunderstood then I apologise. Could someone clarify please?
Cheers,
Chris
On 29 Jul 2015, at 15:45 , Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
On 29 Jul 2015 5:51 am, "Chris Disspain" <ceo@auda.org.au> wrote:.
Let’s assume that the single member has a total of 20 votes (5 each for
ASO, ccNSO, GNSO and ALAC) and that the threshold for the veto is 75%. That means that 15 votes are required.
SO: My understanding was that the 75% is from each SO/AC(i.e ~4 out of 5 votes of each SO/ALAC) and not from total votes casted
Let’s assume that ALAC asks for an allocation of $2,000,000 to run an At Large Summit. At the moment, that is an extraordinary item (i.e. it is not automatically budgeted for each year or each X years) and the process of approval involves, in essence, the Board approving it. Under the veto provision, it would be possible for the ASO, ccNSO and GNSO to vote against the budget because of that line item.
Equally, the ALAC, ccNSO and ASO could vote against a gTLD industry summit line item or a non-commercial users meeting cost. And, entirely the reverse could happen with SOs and ACs 'horse-trading' with each other so that they each get their (to quote you) needs, concerns, demands, objections met.
Is this really what we want to set up?
SO: If my understanding of the 75% above is incorrect then I agree as well; it's definitely not a setup to uphold.
Regards
Cheers,
Chris
On 29 Jul 2015, at 03:02 , Greg Shatan <gregshatanipc@gmail.com>
wrote:
I don't think the budget veto was ever intended to substitute for
community participation in the budget process, rather it was intended to encourage it (in a sort of dark and foreboding way). There are already a number of ways in which the community in general, and SOs and ACs (and their component parts) participate in the budget process, and these have been improving over time. I'm not going to catalogue them here, but I should think it's readily available on the website or from Xavier Calvez's team. These should continue to be improved. One continuing shortcoming is that we are all still supplicants, beseeching ICANN finance for a little more pie. While this is true in private (and public) entities as well, the level of influence of the community is probably lower than it should be. As it is now, the community can register all of its needs, concerns, demands, objections, etc., and in the end there is nothing to make those anything more than "kind requests."
The budget veto is a final backstop in the event of a budget that
fundamentally is at odds with where it should be. The budget veto should not be viewed primarily as a power, as much as an admonishment, to add discipline the budget process. It should constrain the Board from delivering a "veto-able" budget. The best way to avoid that, of course, is communication with and due consideration of the need of the community throughout the process.
One other note -- there seems to be a misunderstanding of what a
"non-profit corporation" (and why it is called "non-profit"). A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced. A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses. There may be a point when sitting on a pile of cash is not consistent with the entity's goals, but that can also be true of a for-profit corporation. It's entirely fair to talk about the numbers, but we should be careful not to bring in presumptions that don't exist. [Caveat: I'm not referring to charitable organizations, which are often referred to as non-profits as well.]
Greg
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <
crg@isoc-cr.org> wrote:
Dear George,
I agree with you that a cumulated budget veto is a pretty useless
accountability tool (independently of how difficult it would be for the sole member to exercise it…)
Moreover, I think the community on the one hand should take care that
the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial
BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called
“checks and balances” than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org Skype: carlos.raulg +506 8837 7173 (cel) +506 4000 2000 (home) +506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <
george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past
this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was
more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto
since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to
control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must
be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be
accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion,
our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we
don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is
IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget
approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Jordan Carter
Chief Executive *InternetNZ*
+64-495-2118 (office) | +64-21-442-649 (mob) Email: jordan@internetnz.net.nz Skype: jordancarter
*A better world through a better Internet *
Hi Chris, Thanks for starting a list of key and concrete scenarios to outline how the proposed measures could work. I think that's useful and am tagging this email for Hillary as this type of use-case would be useful to our communications plan. Le 29/07/2015 06:50, Chris Disspain a écrit :
Let’s assume that the single member has a total of 20 votes (5 each for ASO, ccNSO, GNSO and ALAC) and that the threshold for the veto is 75%. That means that 15 votes are required.
Let’s assume that ALAC asks for an allocation of $2,000,000 to run an At Large Summit. At the moment, that is an extraordinary item (i.e. it is not automatically budgeted for each year or each X years) and the process of approval involves, in essence, the Board approving it. Under the veto provision, it would be possible for the ASO, ccNSO and GNSO to vote against the budget because of that line item.
I note that it would require unanimity outside of ALAC to veto the budget in that scenario. Worth questioning whether that is a useful safeguard or an interference into the matters of ALAC. Another scenario that was considered by this group was a proposal from the Board to allocate a significant part of Icann funds to a summit on Internet governance, for example. Once again, the question is whether the veto and the associated threshold provide a useful safeguard or undue interference.
Equally, the ALAC, ccNSO and ASO could vote against a gTLD industry summit line item or a non-commercial users meeting cost. And, entirely the reverse could happen with SOs and ACs 'horse-trading' with each other so that they each get their (to quote you) needs, concerns, demands, objections met.
Not being a native English speaker, I can't be sure of my understanding of horse-trading. However, once again it's worth considering whether a cross community discussion should take place on which needs, concerns, demands, from the various SOs or ACs should be funded or not, whether we qualify it as "horse-trading" or "cross community coordination in the budgetary process". And once again, the Board gets to propose the budget, just like now, and the veto process would be exceptional and requiring supermajority. Only 33% support and it moves on. I understand the intent of the WS2 item on the budget process to be intended to look at these coordination issues. Best Mathieu
Is this really what we want to set up?
Cheers,
Chris
On 29 Jul 2015, at 03:02 , Greg Shatan <gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com>> wrote:
I don't think the budget veto was ever intended to substitute for community participation in the budget process, rather it was intended to encourage it (in a sort of dark and foreboding way). There are already a number of ways in which the community in general, and SOs and ACs (and their component parts) participate in the budget process, and these have been improving over time. I'm not going to catalogue them here, but I should think it's readily available on the website or from Xavier Calvez's team. These should continue to be improved. One continuing shortcoming is that we are all still supplicants, beseeching ICANN finance for a little more pie. While this is true in private (and public) entities as well, the level of influence of the community is probably lower than it should be. As it is now, the community can register all of its needs, concerns, demands, objections, etc., and in the end there is nothing to make those anything more than "kind requests."
The budget veto is a final backstop in the event of a budget that fundamentally is at odds with where it should be. The budget veto should not be viewed primarily as a power, as much as an admonishment, to add discipline the budget process. It should constrain the Board from delivering a "veto-able" budget. The best way to avoid that, of course, is communication with and due consideration of the need of the community throughout the process.
One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit"). A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced. A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses. There may be a point when sitting on a pile of cash is not consistent with the entity's goals, but that can also be true of a for-profit corporation. It's entirely fair to talk about the numbers, but we should be careful not to bring in presumptions that don't exist. [Caveat: I'm not referring to charitable organizations, which are often referred to as non-profits as well.]
Greg
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org <mailto:crg@isoc-cr.org>> wrote:
Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise it…)
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called “checks and balances” than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: crg@isoc-cr.org <mailto:crg@isoc-cr.org> Skype: carlos.raulg +506 8837 7173 <tel:%2B506%208837%207173> (cel) +506 4000 2000 <tel:%2B506%204000%202000> (home) +506 2290 3678 <tel:%2B506%202290%203678> (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky <george.sadowsky@gmail.com <mailto:george.sadowsky@gmail.com>> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- ***************************** Mathieu WEILL AFNIC - directeur général Tél: +33 1 39 30 83 06 mathieu.weill@afnic.fr Twitter : @mathieuweill *****************************
Hi Mathieu, See below….. Cheers, Chris
On 29 Jul 2015, at 19:31 , Mathieu Weill <mathieu.weill@afnic.fr> wrote:
Hi Chris,
Thanks for starting a list of key and concrete scenarios to outline how the proposed measures could work. I think that's useful and am tagging this email for Hillary as this type of use-case would be useful to our communications plan.
Le 29/07/2015 06:50, Chris Disspain a écrit :
Let’s assume that the single member has a total of 20 votes (5 each for ASO, ccNSO, GNSO and ALAC) and that the threshold for the veto is 75%. That means that 15 votes are required.
Let’s assume that ALAC asks for an allocation of $2,000,000 to run an At Large Summit. At the moment, that is an extraordinary item (i.e. it is not automatically budgeted for each year or each X years) and the process of approval involves, in essence, the Board approving it. Under the veto provision, it would be possible for the ASO, ccNSO and GNSO to vote against the budget because of that line item.
I note that it would require unanimity outside of ALAC to veto the budget in that scenario. Worth questioning whether that is a useful safeguard or an interference into the matters of ALAC.
Another scenario that was considered by this group was a proposal from the Board to allocate a significant part of Icann funds to a summit on Internet governance, for example. Once again, the question is whether the veto and the associated threshold provide a useful safeguard or undue interference.
Well, I think a community wide concern about a general budget item may be different from a concern about an AC or SO specific item. Leaving aside the desirability of a veto, I would expect a ‘community' wide concern about a significant budget expense on Internet governance to carry a high persuasive weight with the Board. I think a concern about a budget expense specific to an SO or AC is different and may deserve different treatment.
Equally, the ALAC, ccNSO and ASO could vote against a gTLD industry summit line item or a non-commercial users meeting cost. And, entirely the reverse could happen with SOs and ACs 'horse-trading' with each other so that they each get their (to quote you) needs, concerns, demands, objections met.
Not being a native English speaker, I can't be sure of my understanding of horse-trading. However, once again it's worth considering whether a cross community discussion should take place on which needs, concerns, demands, from the various SOs or ACs should be funded or not, whether we qualify it as "horse-trading" or "cross community coordination in the budgetary process”.
My apologies for using unclear colloquialisms. I mean that SOs and ACs could ’negotiate’ amongst themselves to secure their own particular ’needs, concerns or demands’. And they would be doing so without any fiduciary responsibility to ICANN ('We will agree to your summit if you agree to ours and we both block theirs’). Not necessarily an issue provided we are happy to create this environment.
And once again, the Board gets to propose the budget, just like now, and the veto process would be exceptional and requiring supermajority. Only 33% support and it moves on.
You seem to be working on 67% requirement to block rather than a 75%. Or to use your way of putting it, you are working on only 33% support required rather than only 25%. That would mean that in my scenario of 20 votes split between 4 SOs/ACs, 13.4 votes would be enough to veto. Leaving aside whether you would round up to 14 or down to 13, that scenario means that the veto wouldn’t even need to be unanimous across 3 SOs/ACs. Again….not necessarily a problem as long as we are clear that this is what we want.
I understand the intent of the WS2 item on the budget process to be intended to look at these coordination issues.
Best Mathieu
Is this really what we want to set up?
Cheers,
Chris
On 29 Jul 2015, at 03:02 , Greg Shatan <gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com>> wrote:
I don't think the budget veto was ever intended to substitute for community participation in the budget process, rather it was intended to encourage it (in a sort of dark and foreboding way). There are already a number of ways in which the community in general, and SOs and ACs (and their component parts) participate in the budget process, and these have been improving over time. I'm not going to catalogue them here, but I should think it's readily available on the website or from Xavier Calvez's team. These should continue to be improved. One continuing shortcoming is that we are all still supplicants, beseeching ICANN finance for a little more pie. While this is true in private (and public) entities as well, the level of influence of the community is probably lower than it should be. As it is now, the community can register all of its needs, concerns, demands, objections, etc., and in the end there is nothing to make those anything more than "kind requests."
The budget veto is a final backstop in the event of a budget that fundamentally is at odds with where it should be. The budget veto should not be viewed primarily as a power, as much as an admonishment, to add discipline the budget process. It should constrain the Board from delivering a "veto-able" budget. The best way to avoid that, of course, is communication with and due consideration of the need of the community throughout the process.
One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit"). A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced. A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses. There may be a point when sitting on a pile of cash is not consistent with the entity's goals, but that can also be true of a for-profit corporation. It's entirely fair to talk about the numbers, but we should be careful not to bring in presumptions that don't exist. [Caveat: I'm not referring to charitable organizations, which are often referred to as non-profits as well.]
Greg
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <crg@isoc-cr.org <mailto:crg@isoc-cr.org>> wrote: Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise it…)
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called “checks and balances” than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
email: <mailto:crg@isoc-cr.org>crg@isoc-cr.org <mailto:crg@isoc-cr.org> Skype: carlos.raulg +506 8837 7173 <tel:%2B506%208837%207173> (cel) +506 4000 2000 <tel:%2B506%204000%202000> (home) +506 2290 3678 <tel:%2B506%202290%203678> (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
On Jul 27, 2015, at 9:30 AM, George Sadowsky < <mailto:george.sadowsky@gmail.com>george.sadowsky@gmail.com <mailto:george.sadowsky@gmail.com>> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list <mailto:Accountability-Cross-Community@icann.org>Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://mm.icann.org/mailman/listinfo/accountability-cross-community>
-- ***************************** Mathieu WEILL AFNIC - directeur général Tél: +33 1 39 30 83 06 mathieu.weill@afnic.fr <mailto:mathieu.weill@afnic.fr> Twitter : @mathieuweill *****************************
My normal refrain on many of these discussions is that if we trust AC/SOs to appoint Board members, we should also presume that they are mature and will not use any of these powers in ways that are less than honourable and free from vindictive purposes. However, with some of the talk going on about the lessened position that ACs should have in this process, I sadly CAN see how there could be an attempt to gang up on one group... Alan At 29/07/2015 08:25 AM, Chris Disspain wrote:
Hi Mathieu,
See below ..
Cheers,
Chris
On 29 Jul 2015, at 19:31 , Mathieu Weill <<mailto:mathieu.weill@afnic.fr>mathieu.weill@afnic.fr> wrote:
Hi Chris,
Thanks for starting a list of key and concrete scenarios to outline how the proposed measures could work. I think that's useful and am tagging this email for Hillary as this type of use-case would be useful to our communications plan.
Le 29/07/2015 06:50, Chris Disspain a écrit :
Lets assume that the single member has a total of 20 votes (5 each for ASO, ccNSO, GNSO and ALAC) and that the threshold for the veto is 75%. That means that 15 votes are required.
Lets assume that ALAC asks for an allocation of $2,000,000 to run an At Large Summit. At the moment, that is an extraordinary item (i.e. it is not automatically budgeted for each year or each X years) and the process of approval involves, in essence, the Board approving it. Under the veto provision, it would be possible for the ASO, ccNSO and GNSO to vote against the budget because of that line item.
I note that it would require unanimity outside of ALAC to veto the budget in that scenario. Worth questioning whether that is a useful safeguard or an interference into the matters of ALAC.
Another scenario that was considered by this group was a proposal from the Board to allocate a significant part of Icann funds to a summit on Internet governance, for example. Once again, the question is whether the veto and the associated threshold provide a useful safeguard or undue interference.
Well, I think a community wide concern about a general budget item may be different from a concern about an AC or SO specific item. Leaving aside the desirability of a veto, I would expect a community' wide concern about a significant budget expense on Internet governance to carry a high persuasive weight with the Board. I think a concern about a budget expense specific to an SO or AC is different and may deserve different treatment.
Equally, the ALAC, ccNSO and ASO could vote against a gTLD industry summit line item or a non-commercial users meeting cost. And, entirely the reverse could happen with SOs and ACs 'horse-trading' with each other so that they each get their (to quote you) needs, concerns, demands, objections met. Not being a native English speaker, I can't be sure of my understanding of horse-trading. However, once again it's worth considering whether a cross community discussion should take place on which needs, concerns, demands, from the various SOs or ACs should be funded or not, whether we qualify it as "horse-trading" or "cross community coordination in the budgetary process.
My apologies for using unclear colloquialisms. I mean that SOs and ACs could negotiate amongst themselves to secure their own particular needs, concerns or demands. And they would be doing so without any fiduciary responsibility to ICANN ('We will agree to your summit if you agree to ours and we both block theirs). Not necessarily an issue provided we are happy to create this environment.
And once again, the Board gets to propose the budget, just like now, and the veto process would be exceptional and requiring supermajority. Only 33% support and it moves on.
You seem to be working on 67% requirement to block rather than a 75%. Or to use your way of putting it, you are working on only 33% support required rather than only 25%. That would mean that in my scenario of 20 votes split between 4 SOs/ACs, 13.4 votes would be enough to veto. Leaving aside whether you would round up to 14 or down to 13, that scenario means that the veto wouldnt even need to be unanimous across 3 SOs/ACs. Again .not necessarily a problem as long as we are clear that this is what we want.
I understand the intent of the WS2 item on the budget process to be intended to look at these coordination issues.
Best Mathieu
Is this really what we want to set up?
Cheers,
Chris
On 29 Jul 2015, at 03:02 , Greg Shatan <<mailto:gregshatanipc@gmail.com>gregshatanipc@gmail.com> wrote:
I don't think the budget veto was ever intended to substitute for community participation in the budget process, rather it was intended to encourage it (in a sort of dark and foreboding way). There are already a number of ways in which the community in general, and SOs and ACs (and their component parts) participate in the budget process, and these have been improving over time. I'm not going to catalogue them here, but I should think it's readily available on the website or from Xavier Calvez's team. These should continue to be improved. One continuing shortcoming is that we are all still supplicants, beseeching ICANN finance for a little more pie. While this is true in private (and public) entities as well, the level of influence of the community is probably lower than it should be. As it is now, the community can register all of its needs, concerns, demands, objections, etc., and in the end there is nothing to make those anything more than "kind requests."
The budget veto is a final backstop in the event of a budget that fundamentally is at odds with where it should be. The budget veto should not be viewed primarily as a power, as much as an admonishment, to add discipline the budget process. It should constrain the Board from delivering a "veto-able" budget. The best way to avoid that, of course, is communication with and due consideration of the need of the community throughout the process.
One other note -- there seems to be a misunderstanding of what a "non-profit corporation" (and why it is called "non-profit"). A "for-profit" corporation pays out net profits to its owners (shareholders or other types of owners). A non-profit does not have owners or shareholders, so it does not pay out profits to anybody. While an entity can be " non-profit," this does not mean it is "non-surplus." "Non-profit" does not mean that it is not supposed to run an excess of revenues over expenses, or have no more assets than it has liabilities. So, this idea of "balance" is misplaced. A non-profit, like a for-profit, needs to balance its books in an accounting sense, but that does not in any way mean that there is a prohibition or even a presumption against having a surplus of cash over expenses. There may be a point when sitting on a pile of cash is not consistent with the entity's goals, but that can also be true of a for-profit corporation. It's entirely fair to talk about the numbers, but we should be careful not to bring in presumptions that don't exist. [Caveat: I'm not referring to charitable organizations, which are often referred to as non-profits as well.]
Greg
On Tue, Jul 28, 2015 at 10:30 AM, Carlos Raúl Gutiérrez <<mailto:crg@isoc-cr.org>crg@isoc-cr.org> wrote: Dear George,
I agree with you that a cumulated budget veto is a pretty useless accountability tool (independently of how difficult it would be for the sole member to exercise it )
Moreover, I think the community on the one hand should take care that the public interest objectives (policy development and compliance functions) are properly funded. It would be much more effective if those separate hose budgets (policy development and compliance functions) would be developed in a bottom up fashion, based on the needs of the community, and through the communities direct involvement. No need for a veto then since the SOs/ACs would be DIRECTLY responsible for their budgets.
On the other hand, it is up to management to guarantee the financial BALANCE of the day to day operations (yes, balance because ICANN purpose is non for profit), as well as guarantee the demands of the community for proper funding of the public interest functions (independently of the line overseer of the functions, which is another black box altogether).
This would be in my view a much more effective system of so called checks and balances than an absolute veto over the cumulated budget, where the community has little knowledge on the different objectives under it was produced, and remains in my eyes will very obscure, independently of the overall sum in relation to the size of the business.
Best
Carlos Raúl Gutiérrez _____________________
<mailto:crg@isoc-cr.org>email: <mailto:crg@isoc-cr.org>crg@isoc-cr.org Skype: carlos.raulg <tel:%2B506%208837%207173>+506 8837 7173 (cel) <tel:%2B506%204000%202000>+506 4000 2000 (home) <tel:%2B506%202290%203678>+506 2290 3678 (fax) _____________________ Apartado 1571-1000 San Jose, COSTA RICA
<mailto:george.sadowsky@gmail.com>On Jul 27, 2015, at 9:30 AM, George Sadowsky <<mailto:george.sadowsky@gmail.com>george.sadowsky@gmail.com> wrote:
All,
These are my personal opinions.
I suspect that the reaction to this post will be, "we are way past this, we've discussed this, and now just help us work on the implementation details." If so, I think that's a mistake, because what I'd like to do is question one of the fundamental assumptions behind what this group is doing.
When this process started, there was general agreement that it was more important to do this right than to do it quickly Unfortunately, this feeling appears to have reversed, with the current sense that it is more important to get it done quickly in the name of the transition than to spend the time needed to do it right. This process is going beyond accountability to a fundamental redesign of ICANN, with IMO inadequate concern for assuring inclusivity of support as well as lack of concern for unanticipated consequences.
So here's what I'd like to contribute ...
I've been uncomfortable with the notion of budgetary control/veto since the idea was first presented. I think that I now know why: in my opinion it solves the wrong problem, and it is the wrong solution to the right problem. Let me explain.
In general, budgetary control is exercised by groups who want to control an aggregate budget, whether for reasons of limiting growth or ensuring that aggregate expenses for a budget do not exceed some measure of income. I don't think that's the case here, although I suppose that under exceptional circumstances it might be.
The alternative is that the control the group appears to want must be by program or even by line item, even though you're planning to use a very blunt instrument -- control over approval of the aggregate budget -- as your tool to accomplish this. If that's the case, then what you really want is programatic control, not budgetary control. If the program is accepted, then subject to resource constraints, it's up to the staff to deliver, and any specific line item or similar objection, however expressed, interferes with the execution of the activity.
If the disagreement is with the program, with the objectives to be accomplished, and how the objectives are to be accomplished, then that is where the control should be exercised. Any budgetary control after that is micromanagement. The response to that is if you don't trust the organization to implement a rather well defined activity, then change the management/staff, don't restrict their resources and let them continue anyway.
I suggest pursuing this line of argument further. In my opinion, our fundamental problem has two components: (1) a persistent inadequate level of trust between groups within the ICANN community, and (2) our inability/unwillingness to create and use structures to deal directly with this situation and improve it. I see the mechanism as starting with a lack of trust -- in Board, management, staff, as well as the ACs and the SOs and their constituent parts -- that generates not only suspicion regarding motives, non-transparent actions, and actions that are not equally favorable to all groups involved, but also the sense that the process is not serving "me" (whoever I am) well and is therefore out of control.
In other words, IMO we have a fundamental problem of trust, and we don't have an effective way to talk about it or to otherwise address it, much less solve it.
The budget rejection process that is being defined by the group is IMO based more upon defining ultimate ("nuclear" if you like) confrontation mechanisms than upon finding cooperative mechanisms to identify and resolve potential conflicts at an earlier stage. It does not address the trust issue, and to the extent that my hypothesis is correct, if not addressed the trust issue will continue to bedevil ICANN activities, in other probably equally destructive ways. Should not this group be equally or more concerned about mechanisms to identify issues and encourage cooperative-based and trust building processes to solve problems as they arise? It does not appear so to me.
In summary, the current approach, gaining more control over budget approval, is based upon a model of checks and balances, and that may be legitimate to some extent. However, I sense that is not the way in which it is planned to be employed. If so, it solves the wrong problem, nad it does not address the real problem. We need a different approach, one of getting to the root of disagreements, real and perceived, that is early and based upon increased cooperation and trust, and we need a way to communicate that encourages this to happen. This is not an easy problem to solve, but IMO it's the real problem that we have to solve, rather than some well meaning but inaccurate proxy representation of it.
Please consider these thoughts in your discussions.
George
_______________________________________________ Accountability-Cross-Community mailing list <mailto:Accountability-Cross-Community@icann.org>Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list <mailto:Accountability-Cross-Community@icann.org>Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list <mailto:Accountability-Cross-Community@icann.org>Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list <mailto:Accountability-Cross-Community@icann.org>Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- ***************************** Mathieu WEILL AFNIC - directeur général Tél: +33 1 39 30 83 06 <mailto:mathieu.weill@afnic.fr>mathieu.weill@afnic.fr Twitter : @mathieuweill *****************************
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
participants (22)
-
Alan Greenberg -
Carlos Raúl Gutiérrez -
Chartier, Mike S -
Chris Disspain -
CW Mail -
Dr Eberhard W Lisse -
Drazek, Keith -
Edward Morris -
Erika Mann -
George Sadowsky -
Greg Shatan -
James Gannon -
Jonathan Zuck -
Jordan Carter -
Jorge.Cancio＠bakom.admin.ch -
Kieren McCarthy -
Mathieu Weill -
Nigel Roberts -
Samantha Eisner -
Seun Ojedeji -
Steve DelBianco -
Thomas Rickert