[AT-Review] comments on Chris' document

Thu Sep 2 08:29:36 UTC 2010

Fabio, All,

Some comments below on Fabio's structural comments. I have not responded
to content comments at this stage.

I will work on the draft over the next couple of days.

For clarity, I am not suggesting that this is how a FINAL version report
will be structured but rather that by using this proposed structure we can
manage our work in an efficient and effective manner.

Cheers,

Chris Disspain | Chief Executive Officer
.au Domain Administration Ltd
T: 1300 732 929 | F: 03 8341 4112
E: ceo at auda.org.au | W:www.auda.org.au

auDA - The Australian Domain Name Administrator

Important Notice - This email may contain information which is
confidential and/or subject to legal privilege, and is intended for the
use of the named addressee only. If you are not the intended recipient,
you must not use, disclose or copy any part of this email. If you have
received this email by mistake, please notify the sender and delete this
message immediately. Please consider the environment before printing this
email.

> -----Original Message-----
> From: at-review-bounces at icann.org [mailto:at-review-bounces at icann.org]
On Behalf
> Of Fabio Colasanti
> Sent: Wednesday, 1 September 2010 22:13
> To: at-review at icann.org
> Subject: [AT-Review] comments on Chris' document
>
> Dear all,
>
> here are some comments on the document.
>
> Chris' text is organised along the following structure
>
> 1.	Purpose of WG
> 2.	Specific Areas to be considered
> 3.	Background research undertaken
> 3.1	Material examined/inputs received
> 3.2	WG understanding of state of play in this area
> 4.	Analysis
> 4.1	Issues examined per "Area" (as defined under 2)
> 5.	Conclusions reached
> 6.	Current mechanisms
> 7.	Recommendations
>
>
> A few comments on the structure.
>
> At the moment there might be gaps/overlaps between the remits of the
> single working groups.   But the four separate documents will eventually
> be integrated into a single one covering the work of the whole RT.
[Chris Disspain] Agreed.
>
> The key part (of each WG / final) document will be "section 4", the list
of
> issues/problem areas examined.
[Chris Disspain] Well, it's A key part rather than THE key part. Some will
say 7 Recommendations is 'THE ' key part:-)
>
> Section 2 "Specific areas to be considered" should be drafted at the
end, as it consists
> essentially in some logical regrouping of the various
> issues discussed under 4.
[Chris Disspain] I agree that some sections are interdependent and for the
final document to make sense, re-drafting by reference to other sections
will be necessary.

   In the case of WG1, I can see a number of
> issues to be discussed that do not fall within the two areas presently
mentioned.
[Chris Disspain] Absolutely. Those 2 areas are not meant to be exclusive
or definitive.
>
> The (many) subsections of section 4 will contain a description of the
questions that we
> have asked ourselves (or that were suggested to us), why they are
possibly relevant to
> Accountability and Transparency issue, our view of their relevance,
importance and
> some outline of the conclusions
> reached on each one.   We should address here also questions that we
> consider silly, if they have been put forward in the public comments we
> have received.   We will say why we consider these issues not to be
> relevant or important.
[Chris Disspain] Yes.
>
> Probably, sections 5, 6 and 7 can be merged into one.   We could imagine
> that this concluding section would have as many parts as the "areas"
> mentioned under 2.   Each part would present a recapping of the
> "conclusions" presented under 4.   It would explain why the area is
> relevant, what is our assessment of the current efforts and our views on
whether these
> efforts would be helped by doing something else/more (i.e.
> the "recommendations").   There could be several recommendations per
> 'area"
[Chris Disspain] I agree but at present my goal was to produce a something
that we can use as a step by step process. Once we come to final drafting
it may very well be that sections/sub-sections can be merged and/or
reordered.
>
> The final document will probably present eight to ten "areas" to be
mentioned under
> section 2 and easily twenty/thirty "questions/issues" to be listed under
section 4.
>
>
> Comments on the content of the document for WG 1
>
> a)	Do the by-laws, policies or procedures governing board selection
> by the Nominating Committee produce in practice their stated aims?
i.e.
> do we have the right "nominated" directors?
> -	Are conflicts of interest adequately addressed?  Should parties
> contracted to ICANN have a member on the Board?   (The issue arose for
the
> RT.)
> -	Is there a case for publishing the names of the candidates?   The
> IETF do publish candidates for official position.
>
> b)	Are directors in a position to effectively discharge their
> fiduciary obligations?
> -	ICANN has been discussing for years the issue of remunerating
> directors?  Should we be addressing this?
> -	What support do directors receive from ICANN's structure to
> perform their duties?  We have heard that quite a lot is being done.  Do
we have a view
> of its adequacy?
>
> c)	Are the steps put in place to provide transparency of the Board's
> decision making process perceived by the ICANN community to achieve
their
> stated purpose?   Are these steps considered sufficient by the RT?
> -	Publication of briefing material.
> -	Report on public comments received (regrouped by main categories
> of positions/alternative courses of action), extent to which each
> alternative/course of action was retained or rejected.   A report on the
> inputs received should be published well ahead of the decision.   At the
> moment of the decision there should be a supplement indicating the
extent to which
> these inputs were taken into account.
> -	Check lists to ensure that that the Board is aware of the
> existence of i) public policy aspects; ii) impacts on given
> constituencies.   And that where these aspects/impacts exist, ICANN has
> received/requested/obtained inputs from GAC (or other bodies) and from
the
> relevant constituencies.   Explanation of the extent to which these
inputs
> could be incorporated into the Board decision.
>
> d)	Staff (this may be treated here or in WG 3).
> -	Is the geographic background of senior ICANN staff sufficiently
> diversified?
> -	Should there be a rule banning performance related bonus linked to
> Board decisions being taken within given deadlines?  Nobody should have
a financial
> interest to speed-up the decision making progress.
>
> e)	Budget (if this item is considered relevant/important it should be
> somewhere, either here or in WG 3).   Revenue enhancing considerations
> should not play a role in ICANN's decisions.   At the moment, ICANN's
> budget appears to be more revenue-driven than cost-driven, and its
growth has
> exceeded any equivalent growth in activity/mandate.  While some growth
is reasonable
> to safeguard the organisation against unexpected costs, the growth of
ICANN's financial
> reserves (approximately $50 mio) now looks
> more than sufficient.   Some external and independent budgetary
mechanism
> might be considered to ensure that revenue does not continually exceed
> costs.   Until such a mechanism is in place, it should also be possible
to
> identify a surplus that could be used for charitable purposes.  ICANN
could indicate
> publicly what charitable/educational/scientific works it carries out in
accordance with its
> status under California law.
>
> All the best,
>
> Fabio
>
>
>
> __________ Information from ESET Smart Security, version of virus
signature database
> 5413 (20100831) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
>
> __________ Information from ESET Smart Security, version of virus
signature database
> 5416 (20100901) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>

__________ Information from ESET Smart Security, version of virus
signature database 5416 (20100901) __________

The message was checked by ESET Smart Security.

http://www.eset.com