[At-review] Current state of Review and discussion documents from Manal & Fabio
Cheryl Langdon-Orr
langdonorr at gmail.com
Thu Apr 15 20:09:05 UTC 2010
Some edits (showing comments etc.,) have been made to both of the review and
discussion documents proffered by Manal and Fabio. To ensure all tools we're
using are in sync, I've inserted below for list archive (and individual
action where needed) a text copy of the current state of each collaboration
document as at 2000 UTC 15th April 2010.
Cheryl Langdon-Orr
(CLO)
*Review and discussion Doc#1*
<text copy as at 2000 UTC 15th April 2010 showing comments>
Accountability and Transparency Review Team
Start-Up Discussion and Documentation
April 2010
· Purpose
o What is the purpose of formation of the RT?
(review ICANN mechanisms for accountability, transparency & public input)
<CLO> this matter has been further discussed in the <FC>Review team:
initial reflections on various issues document below => suggest we move
substantiative discussion on this matter to that document...
· Scope
o What is the scope of work of the RT ?
(Board governance, GAC role & effectiveness, public input reception, support
of ICANN decisions, PDP, previous reviews)
· Objectives
o What are the key objectives of the RT?
(ensuring accountability, ensuring transparency, ensuring interests of
global Internet users are being met, ……
· Membership
o Who are the members of the RT ?
(members, external experts, external consultant, …..)
· Chairman
o Election of the Chair
o Role of the Chair
· Voting Rights
o Chair & members all have equal voting rights
o Consultant does not have voting rights
o External Experts ????
· Decisions
o Consensus
o Reporting reasons of dissenting opinions
o Public Consultation
· Deliverables / Reporting
o What are the expected output or deliverables of the RT?
(20-page report of conclusions and recommendations, annexes containing
evidence used, …..)
o Translation?
· Timetable
o What is the timeline, schedule
(pages 4, 24 of the Draft proposal, *
http://www.icann.org/en/reviews/affirmation/affirmation-reviews-draft-proposal-26dec09-en.pdf
*<http://www.icann.org/en/reviews/affirmation/affirmation-reviews-draft-proposal-26dec09-en.pdf>
)
· Success Indicators
o How can we measure the success of the RT by the end of its review
cycle?
<CLO> What baseline or background information can we bring from our various
AC or SO's? can this be useful in our ability to set KPI's or make success
measurements.
· Conflict of Interest
<CLO> Declarations of Interest from all Members and assistants should be
lodged (we have examples from GNSO-wg's and ALAC) and the principal of
Continuous Disclosure should be adopted as standard practice(and a standing
Agenda Item) for this RT
· Financial resources
(pages 21-21 of the Draft proposal, *
http://www.icann.org/en/reviews/affirmation/affirmation-reviews-draft-proposal-26dec09-en.pdf
*<http://www.icann.org/en/reviews/affirmation/affirmation-reviews-draft-proposal-26dec09-en.pdf>
)
· References
· Review methodology & working methods
o Roles & responsibilities
- <MI> Participatory and empowerment evaluations
(Fig. 4 pages 13 of the Draft proposal, *
http://www.icann.org/en/reviews/affirmation/affirmation-reviews-draft-proposal-26dec09-en.pdf
*<http://www.icann.org/en/reviews/affirmation/affirmation-reviews-draft-proposal-26dec09-en.pdf>
)
o Selection of indicators
o Data gathering tools
o Methods of data analysis
o Qualitative & Quantitative evidence (from ICANN & from Internet
community)
o Members shall abstain from expressing personal opinions not based on
evidence
o Members shall abstain from bringing to the discussion political or
commercial considerations
o Consultant shall abstain from formulating personal judgments and
from influencing the deliberations of the RT
o 9 phases of the review methodology for responding to the AoC
(pages 11-13 of the Draft proposal, *
http://www.icann.org/en/reviews/affirmation/affirmation-reviews-draft-proposal-26dec09-en.pdf
*<http://www.icann.org/en/reviews/affirmation/affirmation-reviews-draft-proposal-26dec09-en.pdf>
)
- <MI> Chatham House Rule
<CLO> AGREE for any 'in camera activity'
<CLO> this matter has been further discussed in the <FC>Review team:
initial reflections on various issues document below => suggest we move
substantiative discussion on this matter and the following sub set to that
document...
· Meetings
o Frequency?
o Venues?
o Duration?
o Preparation of Agenda?
o Recorded or not?
o Records made public or not?
o Remote participation or not?
o Participation of assistants of RT members or not?
· Conference calls
o Frequency?
o Preparation of Agenda?
o Recorded or not?
o Records made public or not?
o Participation of RT members colleagues?
· Mailing List
o Creation
o Membership
o Posting rules
o Administration
· Other online communication tools
· Administrative support
o What is the support needed?
o Support from ICANN?
o Support from RT members?
· Output of meetings
o Report, minutes, summary, ……
<end text copy as at2000 UTC 15th April 2010>
*Review and discussion Doc#2*
<text copy as at 2000 UTC 15th April 2010 showing comments>
*Review team: initial **reflections on various issues*
(posted by Fabio Colasanti on 14 April 2010)
*1**.** **Objective/**Terms of reference:*
* *
The AoC already provides the core of the team's "terms of reference" in
paragraph 9.1 by describing the objective to which ICANN has committed ("*to
maintain and improve robust mechanisms for public input, accountability, and
transparency so as to ensure that the outcomes of its decision-making will
reflect the public interest and be accountable to all stakeholders*") as
well as the 5 sub-objectives. The AOC then states that "ICANN will
organise a review of its execution of the above commitments". *Th**e
contents of para. 9.1 therefore constitute** the objective of the review
team's activities* and can be considered also the essential terms of
reference. It is perhaps useful to consider whether any additional
elaboration of the existing objectives is necessary or indeed appropriate.
One exception may be whether the team feels it is necessary to adopt a
working definition of the terms "accountability", "transparency" and "public
interest" since these terms are not defined in the AoC and different
stakeholders are likely to have different views on what they should mean. To
avoid frustration later in the process, it may better for the review team to
adopt working definitions at the outset so to make the exercise
transparent, rather than seek to initiate a lengthy (and ultimately
inconclusive) search for "universally acceptable" definitions that could
have consensus support from all parts of the community.
<CLO> I think it is essential for us to adopt working definitions of these
terms at the outset. This matter (specifically the definition of "public
interest') has indeed been raised in other ICANN fora.
*2. ** **Draft methodology:*
The draft methodology produced by ICANN staff was a substantial piece of
work, but the approach proposed is now likely to be too complex to implement
in the short time available. The review team therefore needs to *adopt **a
much simplified and "easily implementable**" methodology* that can be
executed quickly and in the most transparent manner. This could include:
*2.**1** **Consultation / evidence gathering*
Ÿ *ICANN staff **should be asked to **produce a report* on how
they have implemented earlier commitments to transparency and accountability
which the review team can then subsequently assess. Staff could be asked
to present their reflections to the first meeting of the review team in
Marina Del Rey in early May. By identifying what assessments have already
been carried out by ICANN to date, the review team can in particular then
avoid duplicating review activities already carried out. A summary of the
ICANN inputs at this stage should be made public and posted for public
comment.
Ÿ This can be combined with *a "general" **public call for
comments* and proposed changes to ICANN's current practices and procedures
with an initial deadline of, say, middle of June. The review team can
then review this public input in their meeting in Brussels in late June.
Ÿ In parallel, *e**ach ICANN Supporting Organisation and
Advisory committee **should be invited to s**ubmit its own** set of**
recommendations* and/or observations through its representative(s) on the
review team. This would have the advantage of making the whole ICANN
community feel involved in the process and minimises the risk of the review
team publishing findings/recommendations that are subsequently
dismissed/rejected by the community. Such inputs could be discussed by the
relevant bodies at the Brussels meeting and submitted to the review team
shortly thereafter.
<CLO> I **strongly support** this approach... (reference here is to all
three parts of the <FC> proposed methodology under 2.1)
*2.**2** **Deliverables / recommendations*
Ÿ The drafting of recommendations by the team could then start
in August/September with a view to posting draft proposals in October.
Ideally,
the proposals should be concise and concrete operationally. It is worth
noting that the AoC *only calls for the review team to produce
recommendations*, not a full report of its deliberations. Clearly, the team
will need to demonstrate the rationale it has employed for any individual
recommendation but focussing on recommendations (which should be no more
than 2-3 pages in length) rather than on a lengthy report of proceedings should
enable the team to save a lot of time and to concentrate its efforts on its
core task.
<CLO> agreed and we may need to form ad-hoc Work Teams (WT's) to most
effectively get initial drafting of our recommendations done. Our output
must be clear, concise and be written to engage the wider community as part
of a greater trust building exercise as well as being a specific measure of
A&T in ICANN.
*2.**3** **Organisation of the work of the Review Team*
Ÿ The AoC states that "*Resulting recommendations of the
reviews will be provided to the Board and posted for public comment*"
without any indication of whether such recommendations should be endorsed
unanimously by the team. While consensus should of course be sought,
unanimity should not be required since this would effectively give the power
of veto to each individual member. A better approach would be to *seek
consensus **as a primary goal, **but **if members maintain different
positions on any particular draft recommendation, **to record **the
different positions*[1]<https://docs.google.com/Doc?id=dgx6b8fs_174dcd5z76c&btr=EmailImport#_ftn1>
. This would also allow the team to avoid lengthy discussions on issues
where there is no agreement – seek consensus but if it doesn't exist, record
the different opinions and move on. (Thought needs to be given to whether
the ex-officio member of the team – the Chairman of the Board – may
need to recluse
himself from having to endorse any proposals given that the recommendations
will be submitted to the Board of which he is a member).
<CLO> agreed and this has become 'standard' practice in many ICANN WG's
already and is enshrined in the draft guidelines for WG's currently being
developed for GNSO WG use as part of their Improvement Implementation
processes (I am part of one of those work teams (WT) perhaps we can
distribute the current draft of this document for perusal by the AT-review
members (let me know and I can arrange) even though it is still a work in
progress... Certainly while we should aim for FULL consensus we should
agree that divergence if view or minority reports are a good way to go
forward when that can not be reached the points made regarding the Chairman
of the Board are well taken and I'm sure there will be other times when
depending on the topic on the table at the time various of our members may
need to recluse ourselves and have that noted for the record.
Ÿ Prior to the first face-to-face meeting (but also through the
process), team members should be encouraged to circulate their views on the
various issues that need to be discussed. Once an issue has benefited from
a first "tour" between members to gauge the level of interest and/or
consensus, a volunteer can be sought to take responsibility for developing
the exchange of views with a view to *developing a recommendation*. (It is
important that developing recommendations remains the key operational
objective since this is the main output expected of the review team in the
AoC). Email exchanges are also useful for ensuring views are recorded
fully and to ensure transparency between team members on their exchanges.
<CLO> agreed (along with use of whatever collaboration tools and archive
methods we are comfortable with) email still tends to be a 1:1 dialog rather
than a group discussion / interaction which can be offered by other methods
even wiki's (which do not need to be public of course but can be used for
redacted public version reporting of our activities if and when we deem that
suitable.
Ÿ Physical meetings will be very important. Given the
logistical difficulties in getting all members together (travel time, costs)
such meetings, when they do take place, should be for at least 2-3 days. If
the first meeting is in Marina del Rey to allow ICANN staff to make
presentations to the team, only one day should be used for such purposes,
with another 1- 1.5 days being available for team exchanges.
<CLO> I agree absolutely the concept of spending more time travelling to a
meeting than at it does NOT impress me at all... We must make maximum use
of the opportunities we have and of the resources committed to this work..
to that end I commented on the recent doodle for the Brussels F2F why were
we not using any Sat time as options to ensure 2 or 2+day commitments... Re
the MdR meeting if we can concentrate staff presentations in the beginning
half+ of the first day (where we can act more like a panel {a good getting
to know each other exercise any way} while Janis is absent then move onto
the substantiative discussion and Agenda issues after that (including the
admin issues) this might be the best use of the short time we actually have
there... I also assume we could convene in after dinner sessions as well
even if that is at the accommodation venue.
Ÿ Private meetings between team members will be very important
if members are to be able to have frank and honest exchanges, and if members
are to have the freedom to change their mind in the face of arguments made
by others. Only having public meetings would risk limiting the
possibilities for team members to engage in frank discussions. *Members
should also decide which sessions should be held under **"**Chatham House
Rules*"[2]<https://docs.google.com/Doc?id=dgx6b8fs_174dcd5z76c&btr=EmailImport#_ftn2>
–
it will not be helpful to building confidence and trust between team members
if all discussions are subsequently widely reported in the community. (The
ICANN Board for example, and many ICANN SOs and ACs, also have some meetings
in public and some in private to allow for open discussions).
<CLO> agreed and the ALAC has an everything is public other than in
exceptional circumstances operating principal but with our interaction/
contribution opportunities (see AT-review Commons / Wiki information /
reference later in this document) we are doing our best to engage our
community publicly in a way they can feel their voice and contributions to
the process is being heard and facilitated. My role is to ensure that we
have a trust model that the community believes in both in these external to
the AT-review team efforts and of course in our eventual methodologies. As
Chair of the ALAC I am accountable to my At-Large and at-large communities,
so hand on heart during and at the end of our work I must be able to say "we
[the AT-review team] have had frank, full and fearless discussion of the
issues of ICANN's A&T and about specific issues the community has desired to
be raised in this predominantly closed fora.
Ÿ Participation: members could be assisted when necessary (e.g.
for translation purposes) although the *emphasis must remain on direct
interaction between the named members*. Assistants should not intervene
themselves, nor should they be able to substitute for a member who is unable
to participate. Remote participation possibilities should be provided in
cases where a member is unable to travel.
<CLO> agreed
Ÿ To the greatest extent possible, the team members should seek
to execute the above tasks between themselves, only taking advantage of
staff support from ICANN on an *ad hoc* basis when necessary. This will
minimise the burden on ICANN staff and *ensure the perception of the
independence of the review team**.*
<CLO> agreed
Ÿ External experts: none have been appointed to date. Given
the short window available to team members, care needs to be given to *avoiding
spending too much time on additional procedures* to access expert advice
when it is required. In order for the team to maintain independence, it
may also be necessary to avoid asking ICANN to identify an expert for any
particular subject.
<CLO> for this initial AT-review, given the constraints we have I agree with
this approach.
Ÿ Indicators: the ICANN staff paper on methodology highlighted
how complex and onerous the collection of such indicators is likely to be.
Moreover, the team members are not going to be in a position to collect
any significant data themselves and instructing an external consultant on
such a task is likely to be very resource intensive (drafting terms of
reference etc). It is also arguable that the concepts of "accountability"
and "transparency" do not lend themselves easily to quantitative analysis.
Merely counting the number of documents ICANN has produced on any key
subject for example is unlikely to be illuminating. A more logical
approach would be to *listen to concerns expressed by stakeholders and then
for the team to determine to what extent such concerns are legitimate* and
how they might be addressed (i.e. by making a recommendation). Such an
approach would not seem to require access to detailed "indicators" or other
quantitative or qualitative methodologies for analytical purposes. Moreover,
that data which is already available can be provided to the team by the
ICANN staff in their presentation materials.
<CLO> I support our consideration of this all be it anecdotal material
based but valid at this stage and considering the time constraints we have
in my view, and would very much like to spend time at our F2F meeting
discussing this issue in far greater detail (perhaps after the initial
presentations by ICANN staff so we have a 'real' frame of reference) at the
MdR meeting... However I do believe that some of the AC & SO's will have
already accumulated some of this material OR (as is the case with the ALAC
who has set up 'commons wiki space' for public at-large and ALS/RALO
specific At-Large input into the AT-review process) we can access primary
(and secondary) source information to complement and validate this proposed
approach to 'data collection'... The pursuit of the more complex collection
of empirical data methodologies should stay on our to look at agenda and may
perhaps be a foundation of some further recommendations of useful metrics
for intersession activity between the current and next AT-review process.
*2.**4** **Follow up ?*
Ÿ The AOC states that ICANN shall "*organise a review …..no
less frequently than every three years*". The review team may therefore
wish to include among its recommendations an indication of when the next
review should take place. Should, for example, the current team be
reconvened one year later to review progress on the implementation of its
recommendations?
<CLO> clearly we need to discuss this fully as there are resource
considerations to take into account, but it is my view that the first
follow up / repeat review after this initial work should be set and
recommended to be at the earliest optimal yet practical time after
completion of this first AT-review work is completed. 12 months out is
likely to be a very suitable point in time for this first subsequent follow
up.
* *
*p**age **4** of **4*
------------------------------
[1]<https://docs.google.com/Doc?id=dgx6b8fs_174dcd5z76c&btr=EmailImport#_ftnref1>
The GAC's operating principles offer a precedent in this
respect: principle 47: "*The GAC shall work to achieve consensus; however,
where consensus is not possible, the Chair* *shall convey the full range of
view expressed by Members to the ICANN Board*".
[2]<https://docs.google.com/Doc?id=dgx6b8fs_174dcd5z76c&btr=EmailImport#_ftnref2>
"When a meeting, or part thereof, is held under the Chatham
House Rule, participants are free to use the information received, but
neither the identity nor the affiliation of the speaker(s), nor that of any
other participant, may be revealed". This rule was developed by the UK "Royal
Institute of International Affairs" (whose home is at Chatham House in
London) "with the aim of providing anonymity to speakers and to encourage
openness and the sharing of information. It is now used throughout the world
as an aid to free discussion. Meetings do not have to take place at Chatham
House, or be organized by Chatham House, to be held under the Rule".
See *http://www.chathamhouse.org.uk/about/chathamhouserule/*<http://www.chathamhouse.org.uk/about/chathamhouserule/>
for
more information.
<end text copy as at 2000 UTC 15th April 2010>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/at-review/attachments/20100416/1e73aeff/attachment.html
More information about the AT-Review
mailing list