[AT-Review] Draft - next version

Thu Oct 21 01:57:50 UTC 2010

RT,

Taking Larry's points below into account, attached is the latest version
with WG4 section removed.  Please review this document and provide any final
edits so we can get it locked down.  I will revise        WG4 separately
factoring in Larry's points and send it to you shortly.  Note that the
footnotes and source references in text remain to be checked for accuracy
and completeness.  As soon as I have finished WG4 I will turn to that task.

Regards,

Brian

From: Larry Strickling [mailto:Lstrickling at ntia.doc.gov] 
Sent: Wednesday, October 20, 2010 6:25 PM
To: briancute at afilias.info; at-review at icann.org;
ugasser at cyber.law.harvard.edu; 'Caroline Nolan';
rfaris at cyber.law.harvard.edu
Subject: RE: [AT-Review] Draft - next version
Importance: High

Brian,

I still have a lot of issues with respect to the findings and
recommendations of Working Group 4.  Some material that I thought was going
to be excised or rewritten has remained in the text.  So here are my
comments/objections.  But so that I just do not raise objections we (or
rather Fiona) are preparing a red-line to deal with my concerns as well as
some organizational issues we have with the current draft.

Findings and Recommendations

I assume these paragraphs represent findings of the ATRT.  If so, I do not
agree with the finding that the ATRT is concerned that "none of the three
accountability mechanisms can review and potentially reverse ICANN decisions
with binding authority."  I agree that others have raised this issue in
comments but I do not believe it is the consensus view of the review team.
Plus I do not understand why we would make that our primary factual finding
when the remaining paragraphs in the section focus more on whether the
various review mechanisms are independent of the Board.  If this paragraph
is reworded to say that the ATRT heard concerns of this nature, I would have
no objection provided that language is added to indicate that we also heard
that having such a mechanism would create a new set of accountability and
transparency issues by assigning to some new, unnamed set of individuals the
power to overturn Board decisions.

In the same section, I cannot agree with the characterization of the
standard for reconsideration requests as being "exceedingly difficult" to
satisfy.  The Bylaws contain a very reasonable standard in terms of seeking
reconsideration of a Board decision and do not agree that a looser standard
would allow more "meaningful" review of Board actions.  Similarly, I cannot
subscribe to the idea in the next paragraph that because IRP decisions are
non-binding, "there is no true accountability for the ICANN Board."  My
view, as articulated in Cambridge, is that creating a binding review process
reduces the accountability of the Board and does not enhance it.  Again, I
do not mind if both competing views are expressed but as currently drafted,
I dissent from the findings.

In the recommendations section, I do not agree to direct the Board to change
the grounds upon which a Reconsideration request is brought to something
"less restrictive," particularly if we ourselves are unable to suggest a new
standard.

In the second IRP paragraph, I do not necessarily agree that the Board must
"improve accessibility [of the IRP process] to the community."  As we have
discussed, the overall set of review mechanisms in the Bylaws provide a
graduated set of options for anyone aggrieved by a Board decision.  The
easiest to invoke is the ombudsman (and I agree with recommendation to
improve the independence of  the ombudsman), then one can seek
reconsideration if there was  a flaw or deficit in the information
considered by the Board in reaching a decision.  Third is the IRP, which
should be the toughest remedy available.  I think we should not disturb this
basic taxonomy of remedies which we do threaten by trying to make each
remedy equally easy for an aggrieved party to use.

In the third IRP paragraph, I thought the majority view was not to propose
an IRP light.

Community Revote.  Since we have spent no time discussing this option in any
substantive way, I object to the finding that we have "doubts whether
community revote would be effective given the extraordinarily high level of
consensus required to re-examine a Board decision."  I'm not saying I
believe a revote is a good idea-only that I do not know enough about it to
have an opinion one way or the other.  

I agree with Fabio's suggestion earlier today to move the legal discussion
earlier in the document but again, we need to state that the issue here is
primarily a policy judgment and that there is difference of views within the
ATRT as to whether off-loading Board decisions to a new, undefined review
panel increases or decreases Board accountability and whether to do so will
just create a new set of A/T issues with respect to the review panel.

Larry

From: at-review-bounces at icann.org [mailto:at-review-bounces at icann.org] On
Behalf Of Brian Cute
Sent: Wednesday, October 20, 2010 12:48 AM
To: at-review at icann.org; ugasser at cyber.law.harvard.edu; 'Caroline Nolan';
rfaris at cyber.law.harvard.edu
Subject: [AT-Review] Draft - next version

RT,

Attached is the next version of the draft which incorporates our discussion
from the call yesterday.  Please note and review the following changes:

Berkman statement of methodology - p.3

Revised description of PPC activities - p. 29

Corrected quote from public comment - pp. 29-30

Cheryl's definition of Cross Community deliberation - p. 29

WG3 Findings - p. 31

WG3 revised recommendation #8 - p.32

WG3 revised recommendation #9 - p.33 

WG4 - please read in entirety.  Substantial edits provided by Chris.

ATRT RFI to ICANN Staff - text from Staff response - p.37-39

California law summary (reviewed and edited by Berkman) - p.42-43

One point from our call that is not yet addressed in the draft is Larry's
point concerning the IRP undertaking de novo review.  Please offer language
for inclusion.

Note that I will do further editing to address grammar, style, structure and
citations.  If anyone has edits to suggest on this front please send them to
me.

Regards,

Brian 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/at-review/attachments/20101020/e64b1622/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ATRTdraftMaster7.1.doc
Type: application/msword
Size: 177152 bytes
Desc: not available
Url : http://mm.icann.org/pipermail/at-review/attachments/20101020/e64b1622/attachment-0001.doc 