Hi,

Does that help?

Apologies, but I think I remain confused. I understand that we still have the ultimate accountability function. Still don't know if there is any other power. First, as far as I remember, we did not get the Power to force a decision against complete inaction. Also I do not believe that it would be the case that there was complete inaction. I am sure that the Board would review the various recommendations of the AOC type review teams. Most reviews contain many recommendations, and the Board could accept some and reject others.

because once the board has made a decision, we are putting in accountability mechanisms to question that decision

Do you mean reconsideration and IRP? thanks avri On 26-Apr-15 14:03, Jonathan Zuck wrote:

Avri,

I completely agree that this is new obligation and that it must find its way into the bylaws.

As for your other question, I think it’s not a question of giving power to a review team but rather to the community to induce the board to accept recommendations from a review team.

To accomplish that, all we need to do an ensure that the board actually considers the recommendations and makes a decision about them, any decision because once the board has made a decision, we are putting in accountability mechanisms to question that decision. The whole that currently exist is in cases of complete /inaction/ on the part of the board.

The best analogy I think can of at the moment is the FTC. The FTC has the ability to hold companies to their promises. Getting companies to post privacy policies is the equivalent of getting them to promise something at which point, they are then subject to FTC review.

Does that help?

Jonathan

*From:*accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] *On Behalf Of *Avri Doria *Sent:* Sunday, April 26, 2015 1:29 PM *To:* accountability-cross-community@icann.org *Subject:* [CCWG-ACCT] the pwoer to enforce AOC type (6.7) recommendations

Hi,

In the draft recommendations (6.7.2):

Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews.

The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations.

We discussed this as a putting a greater obligation onf the Board than it currently has. But I do not understand how that is the case. At this point, it is still up to the Board to agree or not.

In responding to a CWG-IANA based question from an NCSG member on how the IANA Function Review recommendation for a RFP, if such were to ever happen, would be respected by the ICANN Board? Couldn't they just ignore it.

I did not have a response and am wondering what part of the community powers I am forgetting.

This points to the more general question about any recommendation of an AOC type review.

Other than the no-confidence removal of the Board (6.6.6. got to love the numer!), is there anything that gives the AOC-Like review recommendations the sort of Community powers that we have discussed having for budgets, strategy & operational plans (6.6.2) ? Is it possible to include Board rejection of AOC type review recommendations under the category of decision that can be overruled by members? Or is that class of decsion restricted by statute?

Thanks

avri

------------------------------------------------------------------------

Image removed by sender. Avast logo <http://www.avast.com/>

This email has been checked for viruses by Avast antivirus software. www.avast.com <http://www.avast.com/>

--- This email has been checked for viruses by Avast antivirus software. http://www.avast.com

To add to Jonathan's point, Avri - I think the new language creating a positive obligation on the Board to "approve and implement review team recommendations, including recommendations from previous reviews." isn't just reinforcing the status quo. If the Board fails to do this, it then goes up the reconsideration/review thing. this is how we worked around the "what if they just don't decide anything?" problem. cheers Jordan On 27 April 2015 at 07:29, Jonathan Zuck <JZuck@actonline.org> wrote:

I'm saying that both adoption and rejection are reviewable decisions. Inaction would be the failure to make a decision.

Sent from my Windows Phone ------------------------------ From: Avri Doria <avri@acm.org> Sent: 4/26/2015 2:41 PM To: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] the power to enforce AOC type (6.7) recommendations

Hi,

Does that help?

Apologies, but I think I remain confused.

I understand that we still have the ultimate accountability function. Still don't know if there is any other power.

First, as far as I remember, we did not get the Power to force a decision against complete inaction.

Also I do not believe that it would be the case that there was complete inaction. I am sure that the Board would review the various recommendations of the AOC type review teams. Most reviews contain many recommendations, and the Board could accept some and reject others.

because once the board has made a decision, we are putting in accountability mechanisms to question that decision

Do you mean reconsideration and IRP?

thanks avri

On 26-Apr-15 14:03, Jonathan Zuck wrote:

Avri,

I completely agree that this is new obligation and that it must find its way into the bylaws.

As for your other question, I think it's not a question of giving power to a review team but rather to the community to induce the board to accept recommendations from a review team.

To accomplish that, all we need to do an ensure that the board actually considers the recommendations and makes a decision about them, any decision because once the board has made a decision, we are putting in accountability mechanisms to question that decision. The whole that currently exist is in cases of complete *inaction* on the part of the board.

The best analogy I think can of at the moment is the FTC. The FTC has the ability to hold companies to their promises. Getting companies to post privacy policies is the equivalent of getting them to promise something at which point, they are then subject to FTC review.

Does that help?

Jonathan

*From:* accountability-cross-community-bounces@icann.org [ mailto:accountability-cross-community-bounces@icann.org <accountability-cross-community-bounces@icann.org>] *On Behalf Of *Avri Doria *Sent:* Sunday, April 26, 2015 1:29 PM *To:* accountability-cross-community@icann.org *Subject:* [CCWG-ACCT] the pwoer to enforce AOC type (6.7) recommendations

Hi,

In the draft recommendations (6.7.2):

Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews.

The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations.

We discussed this as a putting a greater obligation onf the Board than it currently has. But I do not understand how that is the case. At this point, it is still up to the Board to agree or not.

In responding to a CWG-IANA based question from an NCSG member on how the IANA Function Review recommendation for a RFP, if such were to ever happen, would be respected by the ICANN Board? Couldn't they just ignore it.

I did not have a response and am wondering what part of the community powers I am forgetting.

This points to the more general question about any recommendation of an AOC type review.

Other than the no-confidence removal of the Board (6.6.6. got to love the numer!), is there anything that gives the AOC-Like review recommendations the sort of Community powers that we have discussed having for budgets, strategy & operational plans (6.6.2) ? Is it possible to include Board rejection of AOC type review recommendations under the category of decision that can be overruled by members? Or is that class of decsion restricted by statute?

Thanks

avri

------------------------------

[image: Image removed by sender. Avast logo] <http://www.avast.com/>

This email has been checked for viruses by Avast antivirus software. www.avast.com

------------------------------ [image: Avast logo] <http://www.avast.com/>

This email has been checked for viruses by Avast antivirus software. www.avast.com

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

-- Jordan Carter Chief Executive *InternetNZ* 04 495 2118 (office) | +64 21 442 649 (mob) jordan@internetnz.net.nz Skype: jordancarter *A better world through a better Internet *

hi Avri, all Avri: the proposal was in fact to change this, by adding the following words in the bylaw that would guide all of these reviews, as follows: "The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations." That was how there would be a "reviewable" point that the other mechanisms for holding the board to account would be able to react off - the "we won't decide anything so nothing will be reviewable" risk would be removed because then they wouldn't have been acting. It seems to me though that we actually should preserve the current approach a little more closely, while still preserving the obligation to make a decision. Therefore (and I'd appreciate eyes on this from Steve, Matthew, Fiona etc - the team who helped develop this) - how would this look: Replacing the text in the bullet pointed list at the top of 6.7.2 - this is the part that explains what we are trying to achieve. CURRENT: "Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews." *PROPOSED*: "Require the ICANN board to consider review team recommendations, including recommendations from previous reviews, and make a positive decision to approve and implement such recommendations or, if it has reasons to not do so, to set out its reasons." Replacing the text in the last box of the proposed bylaw that would govern all these AOC style reviews: CURRENT: "The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations." *PROPOSED*: "The final output of all reviews will be published for public comment. The Board shall consider the recommendations and the public comments, and within six months of receipt of the recommendations will either approve and begin implementation, or explain the reasons in each case where there is a recommendation it wishes to defer or not implement. Thoughts? cheers Jordan On 27 April 2015 at 14:59, Avri Doria <avri@acm.org> wrote:

Hi,

Ok, at this point I no longer think I am confused. Thanks for the elucidations.

My current impression is that we have not changed anything with respect to AOC type review recommendations, They will essentially remain the way it they are now. The improvement is that the same reconsideration and IRP measures will have now, will be improved. And of course there is the new non-confidence measure at the end of the road.

While strengthening the redress measures we are not doing anything specific to strengthen the uptake of AOC type review recommendations. If that is what we have decided, I am ok with it, as long as we do not claim that we have added anything to the approval of reports more than we have added to anything else. We probably should remove the line that says

Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews.

Since that is not the case as far as I can tell. What will continue to happen is that the review teams will submit the report, there will be a public comment period, and then the Board will decide what it wants to do with the recommendations. And if the community does not like it, they can, assuming they have standing, can request reconsideration, CEP and IRP.

avri

On 26-Apr-15 17:30, Jordan Carter wrote:

To add to Jonathan's point, Avri - I think the new language creating a positive obligation on the Board to "approve and implement review team recommendations, including recommendations from previous reviews." isn't just reinforcing the status quo. If the Board fails to do this, it then goes up the reconsideration/review thing. this is how we worked around the "what if they just don't decide anything?" problem.

cheers Jordan

On 27 April 2015 at 07:29, Jonathan Zuck <JZuck@actonline.org> wrote:

...

I'm saying that both adoption and rejection are reviewable decisions. Inaction would be the failure to make a decision.

Sent from my Windows Phone ------------------------------ From: Avri Doria <avri@acm.org> Sent: 4/26/2015 2:41 PM To: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] the power to enforce AOC type (6.7) recommendations

Hi,

Does that help?

Apologies, but I think I remain confused.

I understand that we still have the ultimate accountability function. Still don't know if there is any other power.

First, as far as I remember, we did not get the Power to force a decision against complete inaction.

Also I do not believe that it would be the case that there was complete inaction. I am sure that the Board would review the various recommendations of the AOC type review teams. Most reviews contain many recommendations, and the Board could accept some and reject others.

because once the board has made a decision, we are putting in accountability mechanisms to question that decision

Do you mean reconsideration and IRP?

thanks avri

On 26-Apr-15 14:03, Jonathan Zuck wrote:

Avri,

I completely agree that this is new obligation and that it must find its way into the bylaws.

As for your other question, I think it's not a question of giving power to a review team but rather to the community to induce the board to accept recommendations from a review team.

To accomplish that, all we need to do an ensure that the board actually considers the recommendations and makes a decision about them, any decision because once the board has made a decision, we are putting in accountability mechanisms to question that decision. The whole that currently exist is in cases of complete *inaction* on the part of the board.

The best analogy I think can of at the moment is the FTC. The FTC has the ability to hold companies to their promises. Getting companies to post privacy policies is the equivalent of getting them to promise something at which point, they are then subject to FTC review.

Does that help?

Jonathan

*From:* accountability-cross-community-bounces@icann.org [ mailto:accountability-cross-community-bounces@icann.org <accountability-cross-community-bounces@icann.org>] *On Behalf Of *Avri Doria *Sent:* Sunday, April 26, 2015 1:29 PM *To:* accountability-cross-community@icann.org *Subject:* [CCWG-ACCT] the pwoer to enforce AOC type (6.7) recommendations

Hi,

In the draft recommendations (6.7.2):

Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews.

The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations.

We discussed this as a putting a greater obligation onf the Board than it currently has. But I do not understand how that is the case. At this point, it is still up to the Board to agree or not.

In responding to a CWG-IANA based question from an NCSG member on how the IANA Function Review recommendation for a RFP, if such were to ever happen, would be respected by the ICANN Board? Couldn't they just ignore it.

I did not have a response and am wondering what part of the community powers I am forgetting.

This points to the more general question about any recommendation of an AOC type review.

Other than the no-confidence removal of the Board (6.6.6. got to love the numer!), is there anything that gives the AOC-Like review recommendations the sort of Community powers that we have discussed having for budgets, strategy & operational plans (6.6.2) ? Is it possible to include Board rejection of AOC type review recommendations under the category of decision that can be overruled by members? Or is that class of decsion restricted by statute?

Thanks

avri

------------------------------

[image: Image removed by sender. Avast logo] <http://www.avast.com/>

This email has been checked for viruses by Avast antivirus software. www.avast.com

------------------------------ [image: Avast logo] <http://www.avast.com/>

This email has been checked for viruses by Avast antivirus software. www.avast.com

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

-- Jordan Carter

Chief Executive *InternetNZ*

04 495 2118 (office) | +64 21 442 649 (mob) jordan@internetnz.net.nz Skype: jordancarter

*A better world through a better Internet *

------------------------------ [image: Avast logo] <http://www.avast.com/>

This email has been checked for viruses by Avast antivirus software. www.avast.com

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

-- Jordan Carter Chief Executive *InternetNZ* 04 495 2118 (office) | +64 21 442 649 (mob) jordan@internetnz.net.nz Skype: jordancarter *A better world through a better Internet *

Hi, Thanks for these suggestions. I think it offers a good path tto resolving the issue But, personally I do no think that it goes far enough. Just having the Board give it reasons for rejection is not sufficient. Those reasons could be specious, indicate a misunderstanding of the recommendation or be wrong about implementation means and methods. I think that if they are going to reject, they need to not only give their resons, but need to initiate a community process to deal with the issue, whatever it may be. Otherwise, it might sit and fester for another 5 years. avri On 27-Apr-15 03:25, Jordan Carter wrote:

hi Avri, all

Avri: the proposal was in fact to change this, by adding the following words in the bylaw that would guide all of these reviews, as follows:

"The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations."

That was how there would be a "reviewable" point that the other mechanisms for holding the board to account would be able to react off - the "we won't decide anything so nothing will be reviewable" risk would be removed because then they wouldn't have been acting.

It seems to me though that we actually should preserve the current approach a little more closely, while still preserving the obligation to make a decision.

Therefore (and I'd appreciate eyes on this from Steve, Matthew, Fiona etc - the team who helped develop this) - how would this look:

Replacing the text in the bullet pointed list at the top of 6.7.2 - this is the part that explains what we are trying to achieve.

CURRENT: "Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews."

*PROPOSED*: "Require the ICANN board to consider review team recommendations, including recommendations from previous reviews, and make a positive decision to approve and implement such recommendations or, if it has reasons to not do so, to set out its reasons."

Replacing the text in the last box of the proposed bylaw that would govern all these AOC style reviews:

CURRENT: "The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations."

*PROPOSED*: "The final output of all reviews will be published for public comment. The Board shall consider the recommendations and the public comments, and within six months of receipt of the recommendations will either approve and begin implementation, or explain the reasons in each case where there is a recommendation it wishes to defer or not implement.

Thoughts?

cheers Jordan

On 27 April 2015 at 14:59, Avri Doria <avri@acm.org <mailto:avri@acm.org>> wrote:

Hi,

Ok, at this point I no longer think I am confused. Thanks for the elucidations.

My current impression is that we have not changed anything with respect to AOC type review recommendations, They will essentially remain the way it they are now. The improvement is that the same reconsideration and IRP measures will have now, will be improved. And of course there is the new non-confidence measure at the end of the road.

While strengthening the redress measures we are not doing anything specific to strengthen the uptake of AOC type review recommendations. If that is what we have decided, I am ok with it, as long as we do not claim that we have added anything to the approval of reports more than we have added to anything else. We probably should remove the line that says

...

Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews.

Since that is not the case as far as I can tell. What will continue to happen is that the review teams will submit the report, there will be a public comment period, and then the Board will decide what it wants to do with the recommendations. And if the community does not like it, they can, assuming they have standing, can request reconsideration, CEP and IRP.

avri

On 26-Apr-15 17:30, Jordan Carter wrote:

...

To add to Jonathan's point, Avri - I think the new language creating a positive obligation on the Board to "approve and implement review team recommendations, including recommendations from previous reviews." isn't just reinforcing the status quo. If the Board fails to do this, it then goes up the reconsideration/review thing. this is how we worked around the "what if they just don't decide anything?" problem.

cheers Jordan

On 27 April 2015 at 07:29, Jonathan Zuck <JZuck@actonline.org <mailto:JZuck@actonline.org>> wrote:

I'm saying that both adoption and rejection are reviewable decisions. Inaction would be the failure to make a decision.

Sent from my Windows Phone ------------------------------------------------------------------------ From: Avri Doria <mailto:avri@acm.org> Sent: 4/26/2015 2:41 PM To: accountability-cross-community@icann.org <mailto:accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] the power to enforce AOC type (6.7) recommendations

Hi,

...

Does that help?

Apologies, but I think I remain confused.

I understand that we still have the ultimate accountability function. Still don't know if there is any other power.

First, as far as I remember, we did not get the Power to force a decision against complete inaction.

Also I do not believe that it would be the case that there was complete inaction. I am sure that the Board would review the various recommendations of the AOC type review teams. Most reviews contain many recommendations, and the Board could accept some and reject others.

...

because once the board has made a decision, we are putting in accountability mechanisms to question that decision

Do you mean reconsideration and IRP?

thanks avri

On 26-Apr-15 14:03, Jonathan Zuck wrote:

...

Avri,

I completely agree that this is new obligation and that it must find its way into the bylaws.

As for your other question, I think it’s not a question of giving power to a review team but rather to the community to induce the board to accept recommendations from a review team.

To accomplish that, all we need to do an ensure that the board actually considers the recommendations and makes a decision about them, any decision because once the board has made a decision, we are putting in accountability mechanisms to question that decision. The whole that currently exist is in cases of complete /inaction/ on the part of the board.

The best analogy I think can of at the moment is the FTC. The FTC has the ability to hold companies to their promises. Getting companies to post privacy policies is the equivalent of getting them to promise something at which point, they are then subject to FTC review.

Does that help?

Jonathan

*From:*accountability-cross-community-bounces@icann.org <mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] *On Behalf Of *Avri Doria *Sent:* Sunday, April 26, 2015 1:29 PM *To:* accountability-cross-community@icann.org <mailto:accountability-cross-community@icann.org> *Subject:* [CCWG-ACCT] the pwoer to enforce AOC type (6.7) recommendations

Hi,

In the draft recommendations (6.7.2):

Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews.

The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations.

We discussed this as a putting a greater obligation onf the Board than it currently has. But I do not understand how that is the case. At this point, it is still up to the Board to agree or not.

In responding to a CWG-IANA based question from an NCSG member on how the IANA Function Review recommendation for a RFP, if such were to ever happen, would be respected by the ICANN Board? Couldn't they just ignore it.

I did not have a response and am wondering what part of the community powers I am forgetting.

This points to the more general question about any recommendation of an AOC type review.

Other than the no-confidence removal of the Board (6.6.6. got to love the numer!), is there anything that gives the AOC-Like review recommendations the sort of Community powers that we have discussed having for budgets, strategy & operational plans (6.6.2) ? Is it possible to include Board rejection of AOC type review recommendations under the category of decision that can be overruled by members? Or is that class of decsion restricted by statute?

Thanks

avri

------------------------------------------------------------------------

Image removed by sender. Avast logo <http://www.avast.com/>

This email has been checked for viruses by Avast antivirus software. www.avast.com <http://www.avast.com/>

------------------------------------------------------------------------ Avast logo <http://www.avast.com/>

This email has been checked for viruses by Avast antivirus software. www.avast.com <http://www.avast.com/>

_______________________________________________ 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

-- Jordan Carter

Chief Executive *InternetNZ*

04 495 2118 <tel:04%20495%202118> (office) | +64 21 442 649 <tel:%2B64%2021%20442%20649> (mob) jordan@internetnz.net.nz <mailto:jordan@internetnz.net.nz> Skype: jordancarter

/A better world through a better Internet /

------------------------------------------------------------------------ Avast logo <http://www.avast.com/>

This email has been checked for viruses by Avast antivirus software. www.avast.com <http://www.avast.com/>

_______________________________________________ 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

-- Jordan Carter

Chief Executive *InternetNZ*

04 495 2118 <tel:04%20495%202118> (office) | +64 21 442 649 <tel:%2B64%2021%20442%20649> (mob) jordan@internetnz.net.nz <mailto:jordan@internetnz.net.nz> Skype: jordancarter

/A better world through a better Internet /

--- This email has been checked for viruses by Avast antivirus software. http://www.avast.com

We don't need to distinguish in this way, because in either case the processes are available to force a reconsideration. The appetite to do so will be down to how well the Board has set out its logic. It's less likely to get forced into such in the second situation, since by definition that would be simpler to see being a helpful proposal (at least in the eyes of the community review team). Following our doctrine of conservative simplicity I don't think we should prepare other wording... but if you would like to Alan, or Avri, I am certainly open to it. cheers Jordan On 28 April 2015 at 03:39, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:

I have no problem with something like that (but I admit I hadn't thought of it before - we have had very few recommendations that the Board has not accepted).

We might want to treat "No, we will not do that" and "We have concerns and propose an alternative action" differently. Or perhaps not. Reconvening the group that made the Rec is probably the best way to address this. The learning curve might be too steep otherwise. We would not get 100% participation, but surely would get the people who were the strongest on wanting the particular Rec.

Alan

At 27/04/2015 10:42 AM, Avri Doria wrote:

Hi,

Thanks for these suggestions. I think it offers a good path tto resolving the issue

But, personally I do no think that it goes far enough. Just having the Board give it reasons for rejection is not sufficient. Those reasons could be specious, indicate a misunderstanding of the recommendation or be wrong about implementation means and methods. I think that if they are going to reject, they need to not only give their resons, but need to initiate a community process to deal with the issue, whatever it may be. Otherwise, it might sit and fester for another 5 years.

avri

On 27-Apr-15 03:25, Jordan Carter wrote:

hi Avri, all

Avri: the proposal was in fact to change this, by adding the following words in the bylaw that would guide all of these reviews, as follows:

"The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations."

That was how there would be a "reviewable" point that the other mechanisms for holding the board to account would be able to react off - the "we won't decide anything so nothing will be reviewable" risk would be removed because then they wouldn't have been acting.

It seems to me though that we actually should preserve the current approach a little more closely, while still preserving the obligation to make a decision.

Therefore (and I'd appreciate eyes on this from Steve, Matthew, Fiona etc - the team who helped develop this) - how would this look:

Replacing the text in the bullet pointed list at the top of 6.7.2 - this is the part that explains what we are trying to achieve.

CURRENT: "Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews."

*PROPOSED*: "Require the ICANN board to consider review team recommendations, including recommendations from previous reviews, and make a positive decision to approve and implement such recommendations or, if it has reasons to not do so, to set out its reasons."

Replacing the text in the last box of the proposed bylaw that would govern all these AOC style reviews:

CURRENT: "The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations."

*PROPOSED*: "The final output of all reviews will be published for public comment. The Board shall consider the recommendations and the public comments, and within six months of receipt of the recommendations will either approve and begin implementation, or explain the reasons in each case where there is a recommendation it wishes to defer or not implement.

Thoughts?

cheers Jordan

On 27 April 2015 at 14:59, Avri Doria <avri@acm.org> wrote:

Hi, Ok, at this point I no longer think I am confused. Thanks for the elucidations. My current impression is that we have not changed anything with respect to AOC type review recommendations, They will essentially remain the way it they are now. The improvement is that the same reconsideration and IRP measures will have now, will be improved. And of course there is the new non-confidence measure at the end of the road. While strengthening the redress measures we are not doing anything specific to strengthen the uptake of AOC type review recommendations. If that is what we have decided, I am ok with it, as long as we do not claim that we have added anything to the approval of reports more than we have added to anything else. We probably should remove the line that says

Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews.

Since that is not the case as far as I can tell. What will continue to happen is that the review teams will submit the report, there will be a public comment period, and then the Board will decide what it wants to do with the recommendations. And if the community does not like it, they can, assuming they have standing, can request reconsideration, CEP and IRP.

avri On 26-Apr-15 17:30, Jordan Carter wrote:

To add to Jonathan's point, Avri - I think the new language creating a positive obligation on the Board to "approve and implement review team recommendations, including recommendations from previous reviews." isn't just reinforcing the status quo. If the Board fails to do this, it then goes up the reconsideration/review thing. this is how we worked around the "what if they just don't decide anything?" problem. cheers Jordan

On 27 April 2015 at 07:29, Jonathan Zuck <JZuck@actonline.org> wrote: I'm saying that both adoption and rejection are reviewable decisions. Inaction would be the failure to make a decision. Sent from my Windows Phone ------------------------------ From: Avri Doria <avri@acm.org> Sent: 4/26/2015 2:41 PM To: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] the power to enforce AOC type (6.7) recommendations Hi,

Does that help?

Apologies, but I think I remain confused. I understand that we still have the ultimate accountability function. Still don't know if there is any other power. First, as far as I remember, we did not get the Power to force a decision against complete inaction. Also I do not believe that it would be the case that there was complete inaction. I am sure that the Board would review the various recommendations of the AOC type review teams. Most reviews contain many recommendations, and the Board could accept some and reject others.

because once the board has made a decision, we are putting in accountability mechanisms to question that decision

Do you mean reconsideration and IRP? thanks avri On 26-Apr-15 14:03, Jonathan Zuck wrote:

Avri, I completely agree that this is new obligation and that it must find its way into the bylaws.

As for your other question, I think it's not a question of giving power to a review team but rather to the community to induce the board to accept recommendations from a review team.

To accomplish that, all we need to do an ensure that the board actually considers the recommendations and makes a decision about them, any decision because once the board has made a decision, we are putting in accountability mechanisms to question that decision. The whole that currently exist is in cases of complete inaction on the part of the board.

The best analogy I think can of at the moment is the FTC. The FTC has the ability to hold companies to their promises. Getting companies to post privacy policies is the equivalent of getting them to promise something at which point, they are then subject to FTC review.

Does that help? Jonathan

From: accountability-cross-community-bounces@icann.org [ mailto:accountability-cross-community-bounces@icann.org <accountability-cross-community-bounces@icann.org>] On Behalf Of Avri Doria Sent: Sunday, April 26, 2015 1:29 PM To: accountability-cross-community@icann.org Subject: [CCWG-ACCT] the pwoer to enforce AOC type (6.7) recommendations

Hi, In the draft recommendations (6.7.2):

Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews.

The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations.

We discussed this as a putting a greater obligation onf the Board than it currently has. But I do not understand how that is the case. At this point, it is still up to the Board to agree or not. In responding to a CWG-IANA based question from an NCSG member on how the IANA Function Review recommendation for a RFP, if such were to ever happen, would be respected by the ICANN Board? Couldn't they just ignore it. I did not have a response and am wondering what part of the community powers I am forgetting. This points to the more general question about any recommendation of an AOC type review. Other than the no-confidence removal of the Board (6.6.6. got to love the numer!), is there anything that gives the AOC-Like review recommendations the sort of Community powers that we have discussed having for budgets, strategy & operational plans (6.6.2) ? Is it possible to include Board rejection of AOC type review recommendations under the category of decision that can be overruled by members? Or is that class of decsion restricted by statute? Thanks

avri

[image: Image removed by sender.] <http://www.avast.com/> This email has been checked for viruses by Avast antivirus software. www.avast.com

------------------------------ This email has been checked for viruses by Avast antivirus software. www.avast.com

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

-- Jordan Carter Chief Executive InternetNZ

04 495 2118 (office) | +64 21 442 649 (mob) jordan@internetnz.net.nz Skype: jordancarter A better world through a better Internet

------------------------------ This email has been checked for viruses by Avast antivirus software. www.avast.com

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

-- Jordan Carter

Chief Executive InternetNZ

04 495 2118 (office) | +64 21 442 649 (mob) jordan@internetnz.net.nz Skype: jordancarter

A better world through a better Internet

------------------------------ This email has been checked for viruses by Avast antivirus software. www.avast.com

_______________________________________________ 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* 04 495 2118 (office) | +64 21 442 649 (mob) jordan@internetnz.net.nz Skype: jordancarter *A better world through a better Internet *

On 27 Apr 2015, at 21:13, Jordan Carter <jordan@internetnz.net.nz> wrote:

We don't need to distinguish in this way, because in either case the processes are available to force a reconsideration. The appetite to do so will be down to how well the Board has set out its logic. It's less likely to get forced into such in the second situation, since by definition that would be simpler to see being a helpful proposal (at least in the eyes of the community review team).

I support this view. If a Board refuses to accept a Review Team's considered recommendations, a Reconsideration Request is the appropriate next step for those who wish to push it further. As for Thomas' suggestion of a mandatory public comment period, I support that too, but not exceptionally for ATRT-type work. I hope that our core values will establish a strong norm that a public comment period, and usually one of a significant time (say, three months rather than three weeks), should be the usual requirement for any major piece of work. If it's worth establishing a task force to work on it for a year, it's certainly worth asking the community for a quarter. I would ask the CCWG this though: what if the Board persistently fails to hold public comment? What is the recourse? Do we believe the decision not to offer something for public comment is itself subject to RR and IRP? Do we consider community controls over appointment and recall of Directors sufficient -would they ever be used to recall a Board that wasn't interested in holding public comment? Is there anything else to motivate the Board to uphold this as a norm? For myself, I think specific measures are inappropriate and cannot finely predict all the various failures to uphold the core values to which some future Board might succumb. A better, and simpler idea would be that an arrogant and deaf Board be spilled; this would be a powerful motivator for its successors. But the prevailing view on CCWG seems to be against this, as we say we in the Frozen Draft that we prefers to make it as hard as possible to spill the Board without totally removing the power. So if a Board spill for not holding public comments is vanishingly unlikely, I ask: how are these norms incentivised? Malcolm

While I like Jordan's wording I have to say that I have the same reservations as Avri and support the inclusion of a community process to understand and bridge any issues that arise. Matthew On 4/27/2015 3:42 PM, Avri Doria wrote:

Hi,

Thanks for these suggestions. I think it offers a good path tto resolving the issue

But, personally I do no think that it goes far enough. Just having the Board give it reasons for rejection is not sufficient. Those reasons could be specious, indicate a misunderstanding of the recommendation or be wrong about implementation means and methods. I think that if they are going to reject, they need to not only give their resons, but need to initiate a community process to deal with the issue, whatever it may be. Otherwise, it might sit and fester for another 5 years.

avri

On 27-Apr-15 03:25, Jordan Carter wrote:

...

hi Avri, all

Avri: the proposal was in fact to change this, by adding the following words in the bylaw that would guide all of these reviews, as follows:

"The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations."

That was how there would be a "reviewable" point that the other mechanisms for holding the board to account would be able to react off - the "we won't decide anything so nothing will be reviewable" risk would be removed because then they wouldn't have been acting.

It seems to me though that we actually should preserve the current approach a little more closely, while still preserving the obligation to make a decision.

Therefore (and I'd appreciate eyes on this from Steve, Matthew, Fiona etc - the team who helped develop this) - how would this look:

Replacing the text in the bullet pointed list at the top of 6.7.2 - this is the part that explains what we are trying to achieve.

CURRENT: "Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews."

*PROPOSED*: "Require the ICANN board to consider review team recommendations, including recommendations from previous reviews, and make a positive decision to approve and implement such recommendations or, if it has reasons to not do so, to set out its reasons."

Replacing the text in the last box of the proposed bylaw that would govern all these AOC style reviews:

CURRENT: "The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations."

*PROPOSED*: "The final output of all reviews will be published for public comment. The Board shall consider the recommendations and the public comments, and within six months of receipt of the recommendations will either approve and begin implementation, or explain the reasons in each case where there is a recommendation it wishes to defer or not implement.

Thoughts?

cheers Jordan

On 27 April 2015 at 14:59, Avri Doria <avri@acm.org <mailto:avri@acm.org>> wrote:

Hi,

Ok, at this point I no longer think I am confused. Thanks for the elucidations.

My current impression is that we have not changed anything with respect to AOC type review recommendations, They will essentially remain the way it they are now. The improvement is that the same reconsideration and IRP measures will have now, will be improved. And of course there is the new non-confidence measure at the end of the road.

While strengthening the redress measures we are not doing anything specific to strengthen the uptake of AOC type review recommendations. If that is what we have decided, I am ok with it, as long as we do not claim that we have added anything to the approval of reports more than we have added to anything else. We probably should remove the line that says

...

Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews.

Since that is not the case as far as I can tell. What will continue to happen is that the review teams will submit the report, there will be a public comment period, and then the Board will decide what it wants to do with the recommendations. And if the community does not like it, they can, assuming they have standing, can request reconsideration, CEP and IRP.

avri

On 26-Apr-15 17:30, Jordan Carter wrote:

...

To add to Jonathan's point, Avri - I think the new language creating a positive obligation on the Board to "approve and implement review team recommendations, including recommendations from previous reviews." isn't just reinforcing the status quo. If the Board fails to do this, it then goes up the reconsideration/review thing. this is how we worked around the "what if they just don't decide anything?" problem.

cheers Jordan

On 27 April 2015 at 07:29, Jonathan Zuck <JZuck@actonline.org <mailto:JZuck@actonline.org>> wrote:

I'm saying that both adoption and rejection are reviewable decisions. Inaction would be the failure to make a decision.

Sent from my Windows Phone ------------------------------------------------------------------------ From: Avri Doria <mailto:avri@acm.org> Sent: 4/26/2015 2:41 PM To: accountability-cross-community@icann.org <mailto:accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] the power to enforce AOC type (6.7) recommendations

Hi,

...

Does that help?

Apologies, but I think I remain confused.

I understand that we still have the ultimate accountability function. Still don't know if there is any other power.

First, as far as I remember, we did not get the Power to force a decision against complete inaction.

Also I do not believe that it would be the case that there was complete inaction. I am sure that the Board would review the various recommendations of the AOC type review teams. Most reviews contain many recommendations, and the Board could accept some and reject others.

...

because once the board has made a decision, we are putting in accountability mechanisms to question that decision

Do you mean reconsideration and IRP?

thanks avri

On 26-Apr-15 14:03, Jonathan Zuck wrote:

...

Avri,

I completely agree that this is new obligation and that it must find its way into the bylaws.

As for your other question, I think it’s not a question of giving power to a review team but rather to the community to induce the board to accept recommendations from a review team.

To accomplish that, all we need to do an ensure that the board actually considers the recommendations and makes a decision about them, any decision because once the board has made a decision, we are putting in accountability mechanisms to question that decision. The whole that currently exist is in cases of complete /inaction/ on the part of the board.

The best analogy I think can of at the moment is the FTC. The FTC has the ability to hold companies to their promises. Getting companies to post privacy policies is the equivalent of getting them to promise something at which point, they are then subject to FTC review.

Does that help?

Jonathan

*From:*accountability-cross-community-bounces@icann.org <mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] *On Behalf Of *Avri Doria *Sent:* Sunday, April 26, 2015 1:29 PM *To:* accountability-cross-community@icann.org <mailto:accountability-cross-community@icann.org> *Subject:* [CCWG-ACCT] the pwoer to enforce AOC type (6.7) recommendations

Hi,

In the draft recommendations (6.7.2):

Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews.

The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations.

We discussed this as a putting a greater obligation onf the Board than it currently has. But I do not understand how that is the case. At this point, it is still up to the Board to agree or not.

In responding to a CWG-IANA based question from an NCSG member on how the IANA Function Review recommendation for a RFP, if such were to ever happen, would be respected by the ICANN Board? Couldn't they just ignore it.

I did not have a response and am wondering what part of the community powers I am forgetting.

This points to the more general question about any recommendation of an AOC type review.

Other than the no-confidence removal of the Board (6.6.6. got to love the numer!), is there anything that gives the AOC-Like review recommendations the sort of Community powers that we have discussed having for budgets, strategy & operational plans (6.6.2) ? Is it possible to include Board rejection of AOC type review recommendations under the category of decision that can be overruled by members? Or is that class of decsion restricted by statute?

Thanks

avri

------------------------------------------------------------------------

Image removed by sender. Avast logo <http://www.avast.com/>

This email has been checked for viruses by Avast antivirus software. www.avast.com <http://www.avast.com/>

------------------------------------------------------------------------ Avast logo <http://www.avast.com/>

This email has been checked for viruses by Avast antivirus software. www.avast.com <http://www.avast.com/>

_______________________________________________ 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

-- Jordan Carter

Chief Executive *InternetNZ*

04 495 2118 <tel:04%20495%202118> (office) | +64 21 442 649 <tel:%2B64%2021%20442%20649> (mob) jordan@internetnz.net.nz <mailto:jordan@internetnz.net.nz> Skype: jordancarter

/A better world through a better Internet /

------------------------------------------------------------------------ Avast logo <http://www.avast.com/>

This email has been checked for viruses by Avast antivirus software. www.avast.com <http://www.avast.com/>

_______________________________________________ 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

-- Jordan Carter

Chief Executive *InternetNZ*

04 495 2118 <tel:04%20495%202118> (office) | +64 21 442 649 <tel:%2B64%2021%20442%20649> (mob) jordan@internetnz.net.nz <mailto:jordan@internetnz.net.nz> Skype: jordancarter

/A better world through a better Internet /

------------------------------------------------------------------------ Avast logo <http://www.avast.com/>

This email has been checked for viruses by Avast antivirus software. www.avast.com <http://www.avast.com/>

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

-- Matthew Shears Global Internet Policy and Human Rights Center for Democracy & Technology (CDT) + 44 (0)771 247 2987

I think I agree with Thomas on this. There’s going to be plenty of advice coming out of AC s that gets rejected for a variety of reasons. We just need to insure we have a process in place to contest it in what I imagine will be the rare instance in which the community disagrees. From: Thomas Rickert Date: Monday, April 27, 2015 at 12:48 PM To: Matthew Shears Cc: Avri Doria, Accountability Cross Community Subject: Re: [CCWG-ACCT] Hi, Re: the power to enforce AOC type (6.7) recommendations All, it was my understanding that the group would deem it sufficient for the Board to be transparent about where they are with recommendations they get. Establishing another process for cases where recommendations are rejected seems to me a bit over the top. I would assume the Board would not take a decision to reject advice lightly. If it does, there might be good reason and no escalation is needed. Should the Board choose not to adopt recommendations against the community’s wish, the community has more powers and can make sure it gets its will. In the interest of not making processes too complex, I would still be happy with the language offered by Jordan. If you wish a community process, I suggest we make a public comment period mandatory _prior_ to the rejection of recommendations. The Board should then provide a rationale for its intent to reject recommendations, put it out for public comment and then make a final determination. Best, Thomas Am 27.04.2015 um 17:44 schrieb Matthew Shears <mshears@cdt.org<mailto:mshears@cdt.org>>: While I like Jordan's wording I have to say that I have the same reservations as Avri and support the inclusion of a community process to understand and bridge any issues that arise. Matthew On 4/27/2015 3:42 PM, Avri Doria wrote: Hi, Thanks for these suggestions. I think it offers a good path tto resolving the issue But, personally I do no think that it goes far enough. Just having the Board give it reasons for rejection is not sufficient. Those reasons could be specious, indicate a misunderstanding of the recommendation or be wrong about implementation means and methods. I think that if they are going to reject, they need to not only give their resons, but need to initiate a community process to deal with the issue, whatever it may be. Otherwise, it might sit and fester for another 5 years. avri On 27-Apr-15 03:25, Jordan Carter wrote: hi Avri, all Avri: the proposal was in fact to change this, by adding the following words in the bylaw that would guide all of these reviews, as follows: "The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations." That was how there would be a "reviewable" point that the other mechanisms for holding the board to account would be able to react off - the "we won't decide anything so nothing will be reviewable" risk would be removed because then they wouldn't have been acting. It seems to me though that we actually should preserve the current approach a little more closely, while still preserving the obligation to make a decision. Therefore (and I'd appreciate eyes on this from Steve, Matthew, Fiona etc - the team who helped develop this) - how would this look: Replacing the text in the bullet pointed list at the top of 6.7.2 - this is the part that explains what we are trying to achieve. CURRENT: "Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews." PROPOSED: "Require the ICANN board to consider review team recommendations, including recommendations from previous reviews, and make a positive decision to approve and implement such recommendations or, if it has reasons to not do so, to set out its reasons." Replacing the text in the last box of the proposed bylaw that would govern all these AOC style reviews: CURRENT: "The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations." PROPOSED: "The final output of all reviews will be published for public comment. The Board shall consider the recommendations and the public comments, and within six months of receipt of the recommendations will either approve and begin implementation, or explain the reasons in each case where there is a recommendation it wishes to defer or not implement. Thoughts? cheers Jordan On 27 April 2015 at 14:59, Avri Doria <avri@acm.org<mailto:avri@acm.org>> wrote: Hi, Ok, at this point I no longer think I am confused. Thanks for the elucidations. My current impression is that we have not changed anything with respect to AOC type review recommendations, They will essentially remain the way it they are now. The improvement is that the same reconsideration and IRP measures will have now, will be improved. And of course there is the new non-confidence measure at the end of the road. While strengthening the redress measures we are not doing anything specific to strengthen the uptake of AOC type review recommendations. If that is what we have decided, I am ok with it, as long as we do not claim that we have added anything to the approval of reports more than we have added to anything else. We probably should remove the line that says Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews. Since that is not the case as far as I can tell. What will continue to happen is that the review teams will submit the report, there will be a public comment period, and then the Board will decide what it wants to do with the recommendations. And if the community does not like it, they can, assuming they have standing, can request reconsideration, CEP and IRP. avri On 26-Apr-15 17:30, Jordan Carter wrote: To add to Jonathan's point, Avri - I think the new language creating a positive obligation on the Board to "approve and implement review team recommendations, including recommendations from previous reviews." isn't just reinforcing the status quo. If the Board fails to do this, it then goes up the reconsideration/review thing. this is how we worked around the "what if they just don't decide anything?" problem. cheers Jordan On 27 April 2015 at 07:29, Jonathan Zuck <JZuck@actonline.org<mailto:JZuck@actonline.org>> wrote: I'm saying that both adoption and rejection are reviewable decisions. Inaction would be the failure to make a decision. Sent from my Windows Phone ________________________________ From: Avri Doria<mailto:avri@acm.org> Sent: 4/26/2015 2:41 PM To: accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] the power to enforce AOC type (6.7) recommendations Hi, Does that help? Apologies, but I think I remain confused. I understand that we still have the ultimate accountability function. Still don't know if there is any other power. First, as far as I remember, we did not get the Power to force a decision against complete inaction. Also I do not believe that it would be the case that there was complete inaction. I am sure that the Board would review the various recommendations of the AOC type review teams. Most reviews contain many recommendations, and the Board could accept some and reject others. because once the board has made a decision, we are putting in accountability mechanisms to question that decision Do you mean reconsideration and IRP? thanks avri On 26-Apr-15 14:03, Jonathan Zuck wrote: Avri, I completely agree that this is new obligation and that it must find its way into the bylaws. As for your other question, I think it’s not a question of giving power to a review team but rather to the community to induce the board to accept recommendations from a review team. To accomplish that, all we need to do an ensure that the board actually considers the recommendations and makes a decision about them, any decision because once the board has made a decision, we are putting in accountability mechanisms to question that decision. The whole that currently exist is in cases of complete inaction on the part of the board. The best analogy I think can of at the moment is the FTC. The FTC has the ability to hold companies to their promises. Getting companies to post privacy policies is the equivalent of getting them to promise something at which point, they are then subject to FTC review. Does that help? Jonathan From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Avri Doria Sent: Sunday, April 26, 2015 1:29 PM To: accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Subject: [CCWG-ACCT] the pwoer to enforce AOC type (6.7) recommendations Hi, In the draft recommendations (6.7.2): Require the ICANN board to approve and implement review team recommendations, including recommendations from previous reviews. The final output of all reviews will be published for public comment. The Board shall consider approval and begin implementation within six months of receipt of the recommendations. We discussed this as a putting a greater obligation onf the Board than it currently has. But I do not understand how that is the case. At this point, it is still up to the Board to agree or not. In responding to a CWG-IANA based question from an NCSG member on how the IANA Function Review recommendation for a RFP, if such were to ever happen, would be respected by the ICANN Board? Couldn't they just ignore it. I did not have a response and am wondering what part of the community powers I am forgetting. This points to the more general question about any recommendation of an AOC type review. Other than the no-confidence removal of the Board (6.6.6. got to love the numer!), is there anything that gives the AOC-Like review recommendations the sort of Community powers that we have discussed having for budgets, strategy & operational plans (6.6.2) ? Is it possible to include Board rejection of AOC type review recommendations under the category of decision that can be overruled by members? Or is that class of decsion restricted by statute? Thanks avri ________________________________ <Mail-Anhang.jpeg><http://www.avast.com/> This email has been checked for viruses by Avast antivirus software. www.avast.com<http://www.avast.com/> ________________________________ [Avast logo]<http://www.avast.com/> This email has been checked for viruses by Avast antivirus software. www.avast.com<http://www.avast.com/> _______________________________________________ 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 -- Jordan Carter Chief Executive InternetNZ 04 495 2118<tel:04%20495%202118> (office) | +64 21 442 649<tel:%2B64%2021%20442%20649> (mob) jordan@internetnz.net.nz<mailto:jordan@internetnz.net.nz> Skype: jordancarter A better world through a better Internet ________________________________ [Avast logo]<http://www.avast.com/> This email has been checked for viruses by Avast antivirus software. www.avast.com<http://www.avast.com/> _______________________________________________ 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 -- Jordan Carter Chief Executive InternetNZ 04 495 2118<tel:04%20495%202118> (office) | +64 21 442 649<tel:%2B64%2021%20442%20649> (mob) jordan@internetnz.net.nz<mailto:jordan@internetnz.net.nz> Skype: jordancarter A better world through a better Internet ________________________________ [Avast logo]<http://www.avast.com/> This email has been checked for viruses by Avast antivirus software. www.avast.com<http://www.avast.com/> _______________________________________________ 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 -- Matthew Shears Global Internet Policy and Human Rights Center for Democracy & Technology (CDT) + 44 (0)771 247 2987 _______________________________________________ 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