[Ws2-staff_acct] CCWG-Accountability-WS2-StaffAccountability- Draft Recommendations post public comment.

Sun Feb 11 22:20:55 UTC 2018

Jordan - Thank you for the response. 
Dear colleagues,
I do not support the new text for Recommendation 3. As currently drafted, it no longer contains the core concept of service levels, which is vitally important to contracted parties.

It seems to me the new draft is an attempt to address ICANN Board's comments/concerns, despite the wide community support. I have a serious concern about this approach as seems to give more weight to the views of the ICANN Board. From a procedural perspective, I also question whether such treatment of the public comments is consistent with the Charter and the CCWG process. Further, giving people three days over a weekend to respond to almost a complete rewrite (of those recommendations that were put out for public comment) strikes me as unreasonably short.
Jordan wrote: "To the extent that people say "we want service levels yesterday, thanks - this is too weak" my basic response is that we're on a journey to building the ICANN we want, and that progress doesn't usually happen in one step leaps."
While I admire the patience, I find such statement at odds with the purpose of this group, especially in a post IANA transition environment. I never understood why the ICANN Board had no issue with entering the SLA with the RIRs for the IANA Numbering Services before the transition (see https://www.icann.org/stewardship-implementation/service-level-agreement-sla-for-the-iana-numbering-services); yet it constantly opposes a similar SLA with contracted parties post transition. 
I would bring to your attention the following excerpt from the transcript of a speech made by former ICANN CEO Fadi Chehade more than 5 years ago at ICANN 45 Toronto https://archive.icann.org/en/meetings/toronto2012/bitcache/Transcript_%20Welcome%20Ceremony-vid=42829&disposition=attachment&op=download.pdf:

					"Thirdly, we must optimize our services to the growing number of
registries and registrars. They come to ICANN to get their business
done. It is our job to get their work done for them. And that needs to
be raised to a new level of excellence." I would also encourage you to re-read the public comments submitted by the RrSG and the RySG (see excerpts below):

  The
  Registrars consider these two ideas to be the best in the whole report. Our
  reasons are as follows:

  •        They are consistent with the
  customer – supplier arrangement that now characterizes ICANN’s relationship
  to its stakeholders;

  •        They require no new
  organizations; 

  •        They establish clearer
  expectations of everyone in ICANN;

  •        They are practical;

  •        They cause a focus by
  management and staff on what needs to happen between ICANN and its
  stakeholders-customers;

  •       
  They shift attention away from a preoccupation with procedural
  fairness issues, which dominate too much of the internal workings of the
  organization

  •        The SLAs
  are the accountability mechanisms. The idea behind service level agreements
  provides the criteria by which to evaluate the other recommendations of this
  report. 

  The various mechanisms discussed in the Staff Accountability document make sense
  or not insofar as they re-inforce the idea of a service relationship between
  stakeholders and ICANN staff. The ones that the RrSG considers to be
  ineffective, or largely beside the point, were predicated on vagueness as to
  the accountability of ICANN to its customers. 

  Working out the details of the service level agreements will cause a
  salutary improvement in organizational focus and delivery of services, and
  implementing them will cause even more improvement. 

  The report under discussion
  reflects the changes in approach between the old ICANN and the new one: the
  old being focused on procedural fairness, with its quasi-judicial overtones,
  and multiplicity of mechanism and offices, and the new one on rational
  expectations for defined services within defined timeframes.

  The RySG
  welcomes recommendation #4 and expects that such service level guidelines and
  definitions will contribute to creating clear expectations and as such will
  be helpful for contracted parties as well as for individual staff members.

  I hope you will reconsider and reinstate the core concept of service levels in the previous Recommendation #4.
Kind regards,
Pam------------------------------------------------------------------Sender:Jordan Carter <jordan at internetnz.net.nz>Sent at:2018 Feb 10 (Sat) 10:18To:PAMELA LITTLE <pam.little at alibaba-inc.com>Cc:ws2-staff_acct <ws2-staff_acct at icann.org>Subject:Re: [Ws2-staff_acct] CCWG-Accountability-WS2-StaffAccountability- Draft Recommendations post public comment.
Hi all, hi Pam
I'll come to your point about the agenda first - it is one of the matters to discuss but the sub-group hasn't been able to get a quorum for a meeting. That is why no meetings have been held. We have to move the discussion to the plenary in order to close out this work in time, otherwise there will be none of our work in the final recommendations for the community.
I do understand, as I said on that call that did happen, that ICANN at the Board level may have some concerns about the scope of moving to a service levels approach. Do we mean for Board responses to CCWGs? Do we mean for the ICANN travel office? Do we mean for getting all papers for an ICANN meeting available for everyone two weeks ahead of it? Do we mean on the turnaround of staff notes from community working group calls?  That's a reasonable concern in one respect, so that recommendation could have gone further in specifying what we thought was important.
What I don't understand is the Board's basic view that it does not think a service levels, client-focused approach to what the Organisation does would be wrong. I actually think it would be helpful to the relationships between the org and the community by clarifying expectations, and that it would be reasonable to try this in a few areas and then expand it out. 
My view is that if the Board doesn't like that approach, it is their responsibility to have suggested an alternative approach. I've re-read their public comment and I don't think they have done that. 
So to the changes. I believe that the re-drafted recommendation 3 incorporates the most important point of Recommendation 4, which is to standardise and publish guidelines for timeframes for acknowledging and responding to requests from teh community.
When you take that with the rest of the revised rec 3, and the information acquisition activities we have suggested in rec 2, what I think you get is a move towards a more transparent and accountable service delivery model that should meet the essence of what people supported about rec 4.
This to me also touches on another important point. Service levels and commitments per se sit right at the edge of the scope of our group's work - which is not about the overall accountability of ICANN for appropriate service in its role given its limited scope and mission, but is focused on staff accountability.  My view is that the redraft should be able to attract support from the org, the Board and those community submitters who submitted in favour.
To the extent that people say "we want service levels yesterday, thanks - this is too weak" my basic response is that we're on a journey to building the ICANN we want, and that progress doesn't usually happen in one step leaps.

Thoughts? Does this make sense?

cheersJordan 
On 9 February 2018 at 18:33, Pam Little <pam.little at alibaba-inc.com> wrote:
Hi Jordan, 
With regard to the original Recommendation #4, the latest draft looks like a complete re-write to me. But based on the attached staff-prepared summary of public comments, this recommendation seems to have received wide community support (from the RrSG, BC, IPC and RySG), with one opposition from the ICANN board.
 I would also note your comment in the spreadsheet:  "JC - understand the scope concern - do not undedrstand the concern vs expectations. Put on agenda for next week" and according to my calendar there has been no meetings held since our group's last call at 17 January 1900. 
I would be grateful if you could provide a rationale for the decision to reject Recommendaton #4 and the rewrite now reflected in Recommendation #3. Thank you in advance.
Kind regards,
Pam ------------------------------------------------------------------Sender:Bernard Turcotte <turcotte.bernard at gmail.com>Sent at:2018 Feb 9 (Fri) 07:49To:ws2-staff_acct <ws2-staff_acct at icann.org>Subject:[Ws2-staff_acct] CCWG-Accountability-WS2-StaffAccountability- Draft Recommendations post public comment.
All, 
Given the difficulty in getting quorum for meetings of the sub-group coupled with the urgency to complete the review of these recommendations in light of the public comments, so they can be included in the WS2 final report,  a new draft of the recommendations has been produced which incorporates what the rapporteur considers required changes to address the public comments which have been made.
Attached to this email you will find both a clean and a red-lined PDF versions of this draft document for your consideration.
Please provide any significant comments to the list by 23:59 UTC Sunday February 11.
If there are no significant issues are brought up on the list which need to be addressed, this version of the report will be forwarded to the WS2 Plenary as the final recommendations of the Staff Accountability sub-Group.
Should there be no significant comments by the deadline the work of the sub-group will be considered completed and all future meetings will be cancelled including the Wednesday 14 February 0500 UTC meeting.
Thank You.
Bernard Turcotte for Jordan Carter Staff Accountability Rapporteur.

-- 
Jordan CarterGroup Chief ExecutiveInternetNZ
Office: +64 4 495 2118 | Mobile: +64 21 442 649 | Skype: jordancarterEmail: jordan at internetnz.net.nz
A better world through a better Internet 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ws2-staff_acct/attachments/20180212/983faae9/attachment-0001.html>