ICANN ICANN Email List Archives

[comments-ccwg-framework-principles-22feb16]


<<< Chronological Index >>>    <<< Thread Index >>>

comments on "Draft Framework of Principles for Cross Community Working Groups"

  • To: comments-ccwg-framework-principles-22feb16@xxxxxxxxx
  • Subject: comments on "Draft Framework of Principles for Cross Community Working Groups"
  • From: Andrew Sullivan <ajs@xxxxxxxxxxxxxxxxxx>
  • Date: Sun, 10 Apr 2016 22:37:17 -0400

To the CCWG-Principles:

Thank you for the opportunity to comment on "Draft Uniform Framework
for a Cross Community Working Group (CCWG) Life Cycle: Principles and
Recommendations" (henceforth, "Principles"). As issues confront the
entire ICANN community, a common set of principles for operating CCWGs
will be helpful.

After reading the report, and reviewing the charter again, I am struck
by a fairly basic gap in my understanding of the goal. Are CCWGs
intended to make it possible for basic units of organization at ICANN
-- the SOs and ACs -- to work together? Or instead are CCWGs intended
to find a way towards a broader understanding of "community"
consensus, however one defines that community? Reading the charter for
this work did not help me know, and the report leaves my curiosity
unsatisfied.  With that in mind, I have some observations.  I wish to
be perfectly clear that I make these remarks in my personal capacity,
rather than under any affiliation.

Section 4 contains a question about more formalized operating
procedures for CCWGs. Something that I noted while reading
"Principles" was that some things seem extremely tightly specified
while other things do not seem well-specified at all. For instance,
the class structure of who gets to participate and how (members,
participants, and observers) is quite clear, and the decision-making
procedures are carefully specified. At the same time, every CCWG is
expected to work out its own principles of operation and a great deal
of latitude in the construction of charters (or even how they get
built).

It is plain that there are two possible organizational extremes. One
is to make the CCWG mechanisms quite a bit more formalized, and
thereby restrict any new CCWG's options. This has a conspicuous
advantage: it will redue the opportunity to focus on process and
formalism near the beginning of work, allowing more of the initial
effort to be devoted to the substantive issue at the heart of the
CCWG's creation. Such a focus could be valuable given the concerns one
sometimes hears (however justified) that ICANN processes take too long
and are really accessible only to those who have a lot of time.
Similarly, specification of such rules in advance could allow
tentatively-interested parties to judge reliably how much effort is to
be required. Depending on the rules, this could either serve to
broaden the appeal of participating in a CCWG; it could also make
clear that people without certain amounts of time or procedural bent
are simply not good candidates for participation in a CCWG. An
important disadvantage of this approach is that it could make the
resulting CCWG mechanism too inflexible for some use cases.

The second extreme is actually to leave more rules open to be
determined at the time of chartering of the CCWG or else as part of
the initial CCWG work. For example, it is not clear to me why the
distinction between members and participants is strictly necessary,
and it seems possible that in some cases it could be harmful. (Just
for instance, the anticipated changes to ICANN's structure mean that
the accountability of the SOs and ACs becomes an issue. It might not
be regarded as healthy that the SOs and ACs have a strong say in
determining whose consensus is important in evaluating changes to that
accountability.) It would be possible to state the desirable outcome
-- minimal levels of community involvement, minimal levels of
acceptable diversity of background, and so on -- without stating the
mechanism by which to get there. An important disadvantage of this
approach is that the possible CCWG could spend an enormous amount of
community energy on the organizational details, and that could sap the
energy to do the actually desirable work.

The arrangement proposed in "Principles", unfortunately, holds the
potential for the worst of all worlds. On the one hand, because of the
strict rules both that members are appointed by the chartering ACs and SOs,
and that only members are ultimately to be considered in consensus
rulings, people may try to game the membership of a CCWG in order to
produce a membership slanted toward some desired outcome. On the other
hand, the freedom in charter-making allows CCWGs to set up a charter
that can effectively exclude views undesirable to this or that
interest; or that frames questions in a way that the topic appears
closed without having addressed the fundamental issues. In other
words, the overall danger is that the CCWG mechanism could be abused
to manufacture consensus, rather than to broker it. I am not quite
sure what to recommend here, but I suspect that a greater focus on
what would make something legitimately cross-community -- and less focus
on the structural elements of ICANN, SOs, and ACs -- would help.

Such a focus could help answer the following questions as well:

   • Should there be a requirement that all CCWG recommendations must
    be considered by the ICANN Board, if minimum requirements are met
    (similar to the GNSO Policy Development Process)?

    • Should additional mechanisms be developed to deal with
    situations in which Chartering Organizations may disagree or want
    to discontinue their engagement?

    • As the appointment mechanism for members varies across SO/ACs,
    how can CCWG leadership and support staff be kept informed of
    appointments and changes?

    • Are uniform Statements of Interest, or something similar,
    beneficial to the CCWG process?

    • Should specific requirements be listed for the appointment of
    members?

    • Who launches a call for volunteers/participants?

These all seem to me to be questions about mechanism, and the answers
should naturally flow from the basic question of whether CCWGs are
intended to get a sense of the community as a whole, or whether they
are really only mechanisms for collaboration across the formal
structures that already make up ICANN.

Finally, to the question, "Should there be a mechanism to close a CCWG
if it is clear that it will not be possible to produce a final report
or that circumstances have overtaken the need for a CCWG?" I hope we
all agree that the answer must be, "Yes." Nothing is worse than a
mechanism which survives for the sake of formality and completeness
without doing any real work, like some organizational vermiform
appendix or tailbone.  I suggest the goal is easily accomplished by
stating that any CCWG can close itself by determining that it cannot
reach a conclusion or that its work has been overtaken by events.

Best regards,

Andrew Sullivan

-- 
Andrew Sullivan
ajs@xxxxxxxxxxxxxxxxxx


<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy