[CCWG-ACCT] the power to enforce AOC type (6.7) recommendations

Avri Doria avri at acm.org
Mon Apr 27 20:36:54 UTC 2015


Hi,

While I would prefer to see AOC Type recommendations get at least the
degree of consideration GAC advice gets,
if it is decided that this isn't needed, then I will live with it
getting only the degree of consideration the non-governmental  ACs get. 
I still think it puts too much power to refuse in the Board's hands and
I think it a mistake.  Though, I will argue against any indication in
the doc  that we are strengthening the AOC type reviews, as I think we
are actually weakening them, all things considered.

I do not think another comment period is all that useful as there is no
constraint on the Board to listen to what is contributed in another
comment period.

I.e. one of those weakening considerations and in relation to one
comment: while it is true that recommendations of an AOC have largely
been approved,  they have always had the imprimatur of the head of
NTIA.  Remember that is what we will be giving up in this process, thus
weakening it unless we add other measures.

avri



On 27-Apr-15 16:13, Jordan Carter 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).
>
> 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 at mcgill.ca
> <mailto:alan.greenberg at 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 at acm.org
>>>     <mailto:avri at 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 at actonline.org <mailto:JZuck at 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 at acm.org> 
>>                 Sent: 4/26/2015 2:41 PM
>>                 To: accountability-cross-community at icann.org
>>                 <mailto:accountability-cross-community at 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 at icann.org
>>>                     <mailto:accountability-cross-community-bounces at icann.org>
>>>                     [mailto:accountability-cross-community-bounces at icann.org]
>>>                     On Behalf Of Avri Doria
>>>                     Sent: Sunday, April 26, 2015 1:29 PM
>>>                     To: accountability-cross-community at icann.org
>>>                     <mailto:accountability-cross-community at 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. <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. 
>         www.avast.com <http://www.avast.com/>
>
>         _______________________________________________ 
>         Accountability-Cross-Community mailing list 
>         Accountability-Cross-Community at icann.org
>         <mailto:Accountability-Cross-Community at 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 at internetnz.net.nz <mailto:jordan at 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 <http://www.avast.com/>
>
>         _______________________________________________ 
>         Accountability-Cross-Community mailing list 
>         Accountability-Cross-Community at icann.org
>         <mailto:Accountability-Cross-Community at 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 at internetnz.net.nz <mailto:jordan at 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 <http://www.avast.com/>
>
>
>
>     _______________________________________________
>     Accountability-Cross-Community mailing list
>     Accountability-Cross-Community at icann.org
>     <mailto:Accountability-Cross-Community at icann.org>
>     https://mm.icann.org/mailman/listinfo/accountability-cross-community
>     _______________________________________________
>     Accountability-Cross-Community mailing list
>     Accountability-Cross-Community at icann.org
>     <mailto:Accountability-Cross-Community at 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 at internetnz.net.nz <mailto:jordan at internetnz.net.nz>
> Skype: jordancarter
>
> /A better world through a better Internet /
>
>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community



---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150427/df9e6591/attachment.html>


More information about the Accountability-Cross-Community mailing list