[WP1] A comment about advice from advisory committees

Sat Apr 11 10:06:22 UTC 2015

Unless you are BCCing me in, Steve, I received your original email and this
response (and your resend of your original) on the WP1 list.

best
Jordan

On 11 April 2015 at 09:04, Steve Crocker <steve at shinkuro.com> wrote:

>
> On Apr 9, 2015, at 9:20 PM, Jonathan Zuck <JZuck at actonline.org> wrote:
>
> > Steve,
> > Thanks for your thoughtful note. I don't know whether this came through
> the listserv because I'm also on the address list. Presumably, you'll get a
> bounce back message from wp1 and, if it didn't go through, I'm happy to
> forward it to the list.
>
> Thanks.  I did indeed get a bounce message, so my message did not go to
> the wp1 at icann.org list yet.
>
> > I don't believe that anyone is suggesting that all advice must be
> followed by the board but instead simply that the board is responsible for
> explaining their decisions, with which you already agree. The issue being
> raised presently is about empowering the community to induce action, any
> action, by the board. As it stands today, certain members of  community are
> in a position to "appeal" a board decision, ask the board to reconsider a
> decision, etc. under a very special set of circumstances. There is an
> effort afoot to expand the standing for and decrease the cost of such
> appeals. Where there is a gap, however, is in cases where the board simply
> does not act. If no vote was taken, there's nothing to reconsider or to
> review via some form of IRP. At the same time, there's a strong desire to
> refrain from creating a shadow policy organization within the ICANN
> community so the compromise is to empower the community to induce the board
> to make a decision *one way or the other* about a particular
> recommendation. Once an actual decision is made, that decision becomes
> eligible for review by normal (new normal) means. That's it. So if SSAC
> makes a recommendation about dotless domains, the community would be able
> to require that the board take this advice up in a formal way and make a
> decision, any decision, about it.
> >
> > So specifically, no one is arguing that all advice should be followed or
> frankly, that all advice should be formally taken up by the board (though
> some kind of response is expected as you suggest). Instead there might be
> instances in which a failure of the board to even discuss the advice of an
> advisory committee might spur the community to push that advice onto the
> agenda. Is that more clear?
>
> Yes, all of this is clear, but let me add two points.
>
> First, even though the Board is formally in charge, the Board itself,
> consisting of 20 directors and liaisons working part time, is not, by
> itself, capable of doing most of the work you're implying.  Much of the
> actual work is done by staff.
>
> Second, the appeals mechanism we have in place pertain to resolutions
> passed by the Board.  We have not made a practice of passing a resolution
> regarding each piece of advice that we get.   Perhaps that's going to be
> necessary in the future, but even if we adopted that level of formality,
> the substantive decisions will necessarily be made through a more
> businesslike process.
>
> Thanks,
>
> Steve
>
>
>
> >
> > Jonathan
> >
> >
> >
> > Jonathan Zuck
> > President
> > 202-331-2130 X 101 | jzuck at actonline.org | Skype: jvzuck
> >
> > ACT | The App Association
> >
> >
> >
> >
> >
> >
> >
> >
> > ________________________________________
> > From: Steve Crocker <steve.crocker at icann.org>
> > Sent: Thursday, April 9, 2015 8:46 PM
> > To: wp1 at icann.org; Avri Doria; Thomas Rickert; Jonathan Zuck
> > Cc: Steve Crocker
> > Subject: A comment about advice from advisory committees
> >
> > Thomas, Avri and/or Jonathan,
> >
> > I'm not sure if I have posting privileges to wp1.  If this doesn't show
> up there, perhaps one of you could forward it.
> >
> >
> ======================================================================================================
> >
> > The following is from me, not from the full Board or any other group of
> people, and represents my personal view, not an official ICANN position.  I
> am, however, speaking about ICANN processes based on my experience as both
> SSAC chair and ICANN Board member over more than a dozen years.
> >
> > I want to respond to some very particular aspects of the dialog about
> advice from Advisory Committees.  These comments would also apply to advice
> from other entities, e.g. advice -- not policies developed through a formal
> PDP -- from Supporting Organizations or any of their constituencies, from
> working groups, and even from expert panels.
> >
> > The quote from Thomas Rickert's recent note is representative of the
> overall dialog, so I've copied it here.
> >
> > On Apr 9, 2015, at 12:13 PM, Thomas Rickert <rickert at anwaelte.de> wrote:
> >
> >> I still think this is a way the board can be threatened to take action
> requested by the community. Thus, I am not sure the response to the stress
> test would inevitably be "inadequate". Avri's point is a very good one. By
> requesting the Board to provide information on progress made and action /
> inaction, the Board is forced to deal with recommendations and provide a
> rationale for their (in)activity. One of the concerns would certainly be
> around security, stability and resiliency of the DNS. If the Board chooses
> to ignore a recommendation by the SSAC and puts that in writing, inaction
> would likely be a violation of the bylaws we are working on and could lead
> to removing the Board.
> >
> >
> > I see two general thrusts within the dialog.  One is that advice should
> be acknowledged and responded to, and this obviously includes that the
> response should be timely.  The other thrust is that the advice should be
> followed, or, if not, the rationale should be convincing.
> >
> > I'm in unequivocal agreement with the first thrust.  Among other
> reasons, it's simply proper form, i.e. courtesy, as well as smart
> management to acknowledge receipt and to follow up with what was done with
> the advice.  With regret, I acknowledge we have not always handled all
> advice expeditiously and completely.  This is a weakness in internal
> organization, resource allocation and execution, and we are addressing
> this.  It is one of the things I feel strongly about, and I have applied a
> fair amount of pressure on this.  We have created a register for publicly
> keeping track of advice that has come in and for recording the disposition
> of the advice.   It has turned out to be more complicated to do this than
> it first seemed, at least in part because documents containing advice, e.g.
> a report from SSAC, often contain several pieces of advice, each of which
> needs to be understood, recorded, tracked and dealt with.  This effort is
> moving forward, and I hope to be able to report significant progress at the
> next ICANN meeting.
> >
> > I understand the desire for a bylaws change to make this mandatory.  In
> principle, it shouldn't make any difference, but perhaps it will be helpful
> for both Board and staff in the future to see this emphasized in the bylaws
> and not just in our operational practices.  And a bylaw change is indeed in
> the pipeline.  I believe the language will be presented to the community by
> Buenos Aires and we will follow the proper procedures and timeline for
> approving it.  However, repeating what I've already said, the more salient
> issue is getting the process organized, and we are working vigorously on
> this independent of augmenting the bylaws.
> >
> > Regarding the second thrust, the situation is more nuanced, and I speak
> with both the experience of several years as SSAC chair and several years
> on the ICANN Board.  Without exception, each group that has provided advice
> has done so in good faith and with considerable energy.  Every instance of
> advice was thoughtful and earnest.  But that's not sufficient.  I have also
> seen that in some cases, perhaps more than one might first guess, the
> advice is not appropriate or comes from a limited point of view.  Sometimes
> the group creating the advice develops a mindset of believing it has a
> mandate to create the advice and to insist that its advice be followed.
> This is inherently dangerous.  There must be checks and balances.  When I
> was chair of SSAC, I felt strongly -- and said repeatedly -- that it was
> important that SSAC gave advice but did not have the authority to insist on
> its acceptance.  It was up to others to decide whether to accept SSAC's
> advice, and this served as an essential form of feedback and quality
> control.
> >
> > I am not suggesting the Board is in a position to dismiss or counter
> advice from an expert group as if it were an equal or stronger group of
> experts.  We have some very knowledgeable people on the Board, but that's
> not our role and it's not what we do.  What we do instead is to test advice
> we get against a variety of criteria, including feasibility, resources,
> etc. and also against common sense tests of sensibility.
> >
> > Our preference is always to accept advice from the advisory bodies, but
> it's also very important that everyone, including the groups providing the
> advice, keep in mind their mandate is to provide advice and no more.  They
> do not have the authority to implement the advice, and, of course, they are
> not held responsible for the consequences, pro or con, when the advice is
> translated into implementation or, equally, when the advice is not
> implemented.  This is the essential bargain in our advisory process, and
> it's vital we keep in mind this bright line.
> >
> > Steve
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > WP1 mailing list
> > WP1 at icann.org
> > https://mm.icann.org/mailman/listinfo/wp1
>
> _______________________________________________
> WP1 mailing list
> WP1 at icann.org
> https://mm.icann.org/mailman/listinfo/wp1
>

-- 
Jordan Carter

Chief Executive
*InternetNZ*

04 495 2118 (office) | +64 21 442 649 (mob)
jordan at internetnz.net.nz
Skype: jordancarter

*A better world through a better Internet *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/wp1/attachments/20150411/f4a475c1/attachment.html>