Dear Review Team, Attached is the Draft Report for your review. It consolidates all the sections circulated by the Review Team thus far. This document is also available on the wiki<https://community.icann.org/download/attachments/43975118/ATRT2%20Report%205...>. Please note the following: 1. Brian will add text to create a smooth transition from the introduction section to the "templates" or detailed assessment section. 2. Green highlights reference the wiki rows for ease of reference - these will need to be removed before publication. 3. References to New Recommendations made by ATRT 2 and the underlying "templates" or detailed assessments will need to be mapped out and numbered more clearly. 4. I took the liberty to provide several suggested edits in the beginning portion of the draft. 5. Formatting will be standardized later. As you have not specified the method that you would like to follow to consolidate edits and revisions, staff suggests that your individual comments and edits be made in the attached document in redline mode (i.e. track changes) and circulated to all. Once you reach a consensus on which changes should be incorporated in the report, staff will make final revisions to the master document. We will coordinate this with Brian. Please let me, Charla or Alice know if you are experiencing any difficulties with this file - it is quite large. Best regards, Larisa B. Gurnick Consultant/Senior Director, Organizational Reviews Internet Corporation for Assigned Names and Numbers (ICANN) larisa.gurnick@icann.org<mailto:larisa.gurnick@icann.org> 310 383-8995
Hi, What's the deadline on this review by the team? We had talked about it being over the weekend. Is that still the request? thanks avri On 5 Oct 2013, at 20:20, Larisa B. Gurnick wrote:
Dear Review Team, Attached is the Draft Report for your review. It consolidates all the sections circulated by the Review Team thus far. This document is also available on the wiki.
Please note the following: 1. Brian will add text to create a smooth transition from the introduction section to the “templates” or detailed assessment section. 2. Green highlights reference the wiki rows for ease of reference – these will need to be removed before publication. 3. References to New Recommendations made by ATRT 2 and the underlying “templates” or detailed assessments will need to be mapped out and numbered more clearly. 4. I took the liberty to provide several suggested edits in the beginning portion of the draft. 5. Formatting will be standardized later.
As you have not specified the method that you would like to follow to consolidate edits and revisions, staff suggests that your individual comments and edits be made in the attached document in redline mode (i.e. track changes) and circulated to all. Once you reach a consensus on which changes should be incorporated in the report, staff will make final revisions to the master document. We will coordinate this with Brian.
Please let me, Charla or Alice know if you are experiencing any difficulties with this file – it is quite large.
Best regards,
Larisa B. Gurnick Consultant/Senior Director, Organizational Reviews Internet Corporation for Assigned Names and Numbers (ICANN) larisa.gurnick@icann.org 310 383-8995
<ATRT2 Report 5 Oct v.1.docx>_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
Thanks for the question Avri. Given that the draft was circulated later than planned (due to Review Team editing efforts), the request is for all edits be sent in by 2100 UTC on Monday. For purposes of clarity, that would be 5:00p.m. Monday U.S. EDT. I would ask that edits be focused on substance and quality of assessment issues, as opposed to punctuation, grammar etc. The full document will be edited for punctuation grammar, spelling etc. The most important edits from Review Team members would speak to the quality of the assessments. Thank you. Regards, Brian On Sunday, October 6, 2013, Avri Doria wrote:
Hi,
What's the deadline on this review by the team? We had talked about it being over the weekend. Is that still the request?
thanks
avri
On 5 Oct 2013, at 20:20, Larisa B. Gurnick wrote:
Dear Review Team, Attached is the Draft Report for your review. It consolidates all the sections circulated by the Review Team thus far. This document is also available on the wiki.
Please note the following: 1. Brian will add text to create a smooth transition from the introduction section to the “templates” or detailed assessment section. 2. Green highlights reference the wiki rows for ease of reference – these will need to be removed before publication. 3. References to New Recommendations made by ATRT 2 and the underlying “templates” or detailed assessments will need to be mapped out and numbered more clearly. 4. I took the liberty to provide several suggested edits in the beginning portion of the draft. 5. Formatting will be standardized later.
As you have not specified the method that you would like to follow to consolidate edits and revisions, staff suggests that your individual comments and edits be made in the attached document in redline mode (i.e. track changes) and circulated to all. Once you reach a consensus on which changes should be incorporated in the report, staff will make final revisions to the master document. We will coordinate this with Brian.
Please let me, Charla or Alice know if you are experiencing any difficulties with this file – it is quite large.
Best regards,
Larisa B. Gurnick Consultant/Senior Director, Organizational Reviews Internet Corporation for Assigned Names and Numbers (ICANN) larisa.gurnick@icann.org 310 383-8995
<ATRT2 Report 5 Oct v.1.docx>_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
Please also note that the new Recommendations arising out of ATRT1 assessments do not yet appear in the list of new Recommendations in the introduction section of the Report. They will. I just did not have time to pull them into that list. Brian On Sun, Oct 6, 2013 at 8:52 AM, Brian Cute <brianacute@gmail.com> wrote:
Thanks for the question Avri. Given that the draft was circulated later than planned (due to Review Team editing efforts), the request is for all edits be sent in by 2100 UTC on Monday. For purposes of clarity, that would be 5:00p.m. Monday U.S. EDT.
I would ask that edits be focused on substance and quality of assessment issues, as opposed to punctuation, grammar etc. The full document will be edited for punctuation grammar, spelling etc. The most important edits from Review Team members would speak to the quality of the assessments. Thank you.
Regards, Brian
On Sunday, October 6, 2013, Avri Doria wrote:
Hi,
What's the deadline on this review by the team? We had talked about it being over the weekend. Is that still the request?
thanks
avri
On 5 Oct 2013, at 20:20, Larisa B. Gurnick wrote:
Dear Review Team, Attached is the Draft Report for your review. It consolidates all the sections circulated by the Review Team thus far. This document is also available on the wiki.
Please note the following: 1. Brian will add text to create a smooth transition from the introduction section to the “templates” or detailed assessment section. 2. Green highlights reference the wiki rows for ease of reference – these will need to be removed before publication. 3. References to New Recommendations made by ATRT 2 and the underlying “templates” or detailed assessments will need to be mapped out and numbered more clearly. 4. I took the liberty to provide several suggested edits in the beginning portion of the draft. 5. Formatting will be standardized later.
As you have not specified the method that you would like to follow to consolidate edits and revisions, staff suggests that your individual comments and edits be made in the attached document in redline mode (i.e. track changes) and circulated to all. Once you reach a consensus on which changes should be incorporated in the report, staff will make final revisions to the master document. We will coordinate this with Brian.
Please let me, Charla or Alice know if you are experiencing any difficulties with this file – it is quite large.
Best regards,
Larisa B. Gurnick Consultant/Senior Director, Organizational Reviews Internet Corporation for Assigned Names and Numbers (ICANN) larisa.gurnick@icann.org 310 383-8995
<ATRT2 Report 5 Oct v.1.docx>_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
Dear Larisa. Thank you very much for this. I think that all ATRT2 members highly appreciate that the task taking all the "bits and pieces" and put it all together into a consolidated report is a very big and demanding task which nobody envies you. Having said this I also want to stress that it is of the utmost importance that the texts you use in this process are the right ones. Due to the very short time for commenting I have not been able to check whether all the texts included in the report are the right ones. But I am somewhat worried that two of the texts reflected in the report are not the correct versions. I am talking about the text of October 2, 2013 on ICANN's Finances (already pointed out today by Lise) and the text of October 2, 2013 on GAC Related Recommendations. For your convenience I attach the correct versions of both documents. I kindly ask you to make the relevant corrections. I hope that other documents are reflected in the report in accordance with the latest and approved versions. As a general remark I hope that there will be a possibility to do some editing of the report - may be not now but before the final report is delivered - to make it more easy to read and understand. For outsiders it may be a bit difficult to find the logic. Best regards Jørgen ________________________________ Fra: atrt2-bounces@icann.org [mailto:atrt2-bounces@icann.org] På vegne af Larisa B. Gurnick Sendt: 6. oktober 2013 02:21 Til: ATRT2 (atrt2@icann.org) Emne: [atrt2] Draft Report - version 1 for review Dear Review Team, Attached is the Draft Report for your review. It consolidates all the sections circulated by the Review Team thus far. This document is also available on the wiki<https://community.icann.org/download/attachments/43975118/ATRT2%20Report%205...>. Please note the following: 1. Brian will add text to create a smooth transition from the introduction section to the "templates" or detailed assessment section. 2. Green highlights reference the wiki rows for ease of reference - these will need to be removed before publication. 3. References to New Recommendations made by ATRT 2 and the underlying "templates" or detailed assessments will need to be mapped out and numbered more clearly. 4. I took the liberty to provide several suggested edits in the beginning portion of the draft. 5. Formatting will be standardized later. As you have not specified the method that you would like to follow to consolidate edits and revisions, staff suggests that your individual comments and edits be made in the attached document in redline mode (i.e. track changes) and circulated to all. Once you reach a consensus on which changes should be incorporated in the report, staff will make final revisions to the master document. We will coordinate this with Brian. Please let me, Charla or Alice know if you are experiencing any difficulties with this file - it is quite large. Best regards, Larisa B. Gurnick Consultant/Senior Director, Organizational Reviews Internet Corporation for Assigned Names and Numbers (ICANN) larisa.gurnick@icann.org<mailto:larisa.gurnick@icann.org> 310 383-8995
Jørgen, Thank you for highlighting updates to be incorporated in the report; these updated have now been incorporated. Staff is working closely with Brian, Paul and the Vice Chairs to ensure that the compilation of the report is accurate and consistent with the Review Team's latest work. As you pointed out, this is a detailed and time consuming task, particularly as the content is still getting revised and updated. As the draft report is being reviewed and edited by Brian and several others, staff would very much appreciate the content owners pointing out any other inconsistencies that need to be fixed. An updated version of the draft report will be circulated to the Review Team tomorrow for further review. Best regards, Larisa From: Jørgen C Abild Andersen [mailto:jocaan@erst.dk] Sent: Monday, October 07, 2013 7:41 AM To: Larisa B. Gurnick; ATRT2 (atrt2@icann.org) Subject: SV: Draft Report - version 1 for review Dear Larisa. Thank you very much for this. I think that all ATRT2 members highly appreciate that the task taking all the "bits and pieces" and put it all together into a consolidated report is a very big and demanding task which nobody envies you. Having said this I also want to stress that it is of the utmost importance that the texts you use in this process are the right ones. Due to the very short time for commenting I have not been able to check whether all the texts included in the report are the right ones. But I am somewhat worried that two of the texts reflected in the report are not the correct versions. I am talking about the text of October 2, 2013 on ICANN's Finances (already pointed out today by Lise) and the text of October 2, 2013 on GAC Related Recommendations. For your convenience I attach the correct versions of both documents. I kindly ask you to make the relevant corrections. I hope that other documents are reflected in the report in accordance with the latest and approved versions. As a general remark I hope that there will be a possibility to do some editing of the report - may be not now but before the final report is delivered - to make it more easy to read and understand. For outsiders it may be a bit difficult to find the logic. Best regards Jørgen ________________________________ Fra: atrt2-bounces@icann.org<mailto:atrt2-bounces@icann.org> [mailto:atrt2-bounces@icann.org] På vegne af Larisa B. Gurnick Sendt: 6. oktober 2013 02:21 Til: ATRT2 (atrt2@icann.org<mailto:atrt2@icann.org>) Emne: [atrt2] Draft Report - version 1 for review Dear Review Team, Attached is the Draft Report for your review. It consolidates all the sections circulated by the Review Team thus far. This document is also available on the wiki<https://community.icann.org/download/attachments/43975118/ATRT2%20Report%205...>. Please note the following: 1. Brian will add text to create a smooth transition from the introduction section to the "templates" or detailed assessment section. 2. Green highlights reference the wiki rows for ease of reference - these will need to be removed before publication. 3. References to New Recommendations made by ATRT 2 and the underlying "templates" or detailed assessments will need to be mapped out and numbered more clearly. 4. I took the liberty to provide several suggested edits in the beginning portion of the draft. 5. Formatting will be standardized later. As you have not specified the method that you would like to follow to consolidate edits and revisions, staff suggests that your individual comments and edits be made in the attached document in redline mode (i.e. track changes) and circulated to all. Once you reach a consensus on which changes should be incorporated in the report, staff will make final revisions to the master document. We will coordinate this with Brian. Please let me, Charla or Alice know if you are experiencing any difficulties with this file - it is quite large. Best regards, Larisa B. Gurnick Consultant/Senior Director, Organizational Reviews Internet Corporation for Assigned Names and Numbers (ICANN) larisa.gurnick@icann.org<mailto:larisa.gurnick@icann.org> 310 383-8995
Many thanks, Larisa. Jørgen ________________________________ Fra: Larisa B. Gurnick [mailto:larisa.gurnick@icann.org] Sendt: 8. oktober 2013 15:44 Til: Jørgen C Abild Andersen; ATRT2 (atrt2@icann.org) Emne: RE: Draft Report - version 1 for review Jørgen, Thank you for highlighting updates to be incorporated in the report; these updated have now been incorporated. Staff is working closely with Brian, Paul and the Vice Chairs to ensure that the compilation of the report is accurate and consistent with the Review Team's latest work. As you pointed out, this is a detailed and time consuming task, particularly as the content is still getting revised and updated. As the draft report is being reviewed and edited by Brian and several others, staff would very much appreciate the content owners pointing out any other inconsistencies that need to be fixed. An updated version of the draft report will be circulated to the Review Team tomorrow for further review. Best regards, Larisa From: Jørgen C Abild Andersen [mailto:jocaan@erst.dk] Sent: Monday, October 07, 2013 7:41 AM To: Larisa B. Gurnick; ATRT2 (atrt2@icann.org) Subject: SV: Draft Report - version 1 for review Dear Larisa. Thank you very much for this. I think that all ATRT2 members highly appreciate that the task taking all the "bits and pieces" and put it all together into a consolidated report is a very big and demanding task which nobody envies you. Having said this I also want to stress that it is of the utmost importance that the texts you use in this process are the right ones. Due to the very short time for commenting I have not been able to check whether all the texts included in the report are the right ones. But I am somewhat worried that two of the texts reflected in the report are not the correct versions. I am talking about the text of October 2, 2013 on ICANN's Finances (already pointed out today by Lise) and the text of October 2, 2013 on GAC Related Recommendations. For your convenience I attach the correct versions of both documents. I kindly ask you to make the relevant corrections. I hope that other documents are reflected in the report in accordance with the latest and approved versions. As a general remark I hope that there will be a possibility to do some editing of the report - may be not now but before the final report is delivered - to make it more easy to read and understand. For outsiders it may be a bit difficult to find the logic. Best regards Jørgen ________________________________ Fra: atrt2-bounces@icann.org<mailto:atrt2-bounces@icann.org> [mailto:atrt2-bounces@icann.org] På vegne af Larisa B. Gurnick Sendt: 6. oktober 2013 02:21 Til: ATRT2 (atrt2@icann.org<mailto:atrt2@icann.org>) Emne: [atrt2] Draft Report - version 1 for review Dear Review Team, Attached is the Draft Report for your review. It consolidates all the sections circulated by the Review Team thus far. This document is also available on the wiki<https://community.icann.org/download/attachments/43975118/ATRT2%20Report%205...>. Please note the following: 1. Brian will add text to create a smooth transition from the introduction section to the "templates" or detailed assessment section. 2. Green highlights reference the wiki rows for ease of reference - these will need to be removed before publication. 3. References to New Recommendations made by ATRT 2 and the underlying "templates" or detailed assessments will need to be mapped out and numbered more clearly. 4. I took the liberty to provide several suggested edits in the beginning portion of the draft. 5. Formatting will be standardized later. As you have not specified the method that you would like to follow to consolidate edits and revisions, staff suggests that your individual comments and edits be made in the attached document in redline mode (i.e. track changes) and circulated to all. Once you reach a consensus on which changes should be incorporated in the report, staff will make final revisions to the master document. We will coordinate this with Brian. Please let me, Charla or Alice know if you are experiencing any difficulties with this file - it is quite large. Best regards, Larisa B. Gurnick Consultant/Senior Director, Organizational Reviews Internet Corporation for Assigned Names and Numbers (ICANN) larisa.gurnick@icann.org<mailto:larisa.gurnick@icann.org> 310 383-8995
Larisa, Paul and I continue to edit the full Report. Hoping to have it in shape to circulate to the team today for one last look before sending to the translation team. Thank you. Best, Brian On Tue, Oct 8, 2013 at 9:44 AM, Larisa B. Gurnick <larisa.gurnick@icann.org>wrote:
Jørgen,****
Thank you for highlighting updates to be incorporated in the report; these updated have now been incorporated. Staff is working closely with Brian, Paul and the Vice Chairs to ensure that the compilation of the report is accurate and consistent with the Review Team’s latest work. As you pointed out, this is a detailed and time consuming task, particularly as the content is still getting revised and updated. ****
** **
As the draft report is being reviewed and edited by Brian and several others, staff would very much appreciate the content owners pointing out any other inconsistencies that need to be fixed. An updated version of the draft report will be circulated to the Review Team tomorrow for further review.****
** **
Best regards,****
Larisa****
*From:* Jørgen C Abild Andersen [mailto:jocaan@erst.dk] *Sent:* Monday, October 07, 2013 7:41 AM *To:* Larisa B. Gurnick; ATRT2 (atrt2@icann.org) *Subject:* SV: Draft Report - version 1 for review****
** **
Dear Larisa.****
****
Thank you very much for this. ****
****
I think that all ATRT2 members highly appreciate that the task taking all the "bits and pieces" and put it all together into a consolidated report is a very big and demanding task which nobody envies you. Having said this I also want to stress that it is of the utmost importance that the texts you use in this process are the right ones. Due to the very short time for commenting I have not been able to check whether all the texts included in the report are the right ones. But I am somewhat worried that two of the texts reflected in the report are not the correct versions. I am talking about the text of October 2, 2013 on ICANN's Finances (already pointed out today by Lise) and the text of October 2, 2013 on GAC Related Recommendations. For your convenience I attach the correct versions of both documents. ****
****
I kindly ask you to make the relevant corrections. ****
****
I hope that other documents are reflected in the report in accordance with the latest and approved versions.****
****
As a general remark I hope that there will be a possibility to do some editing of the report - may be not now but before the final report is delivered - to make it more easy to read and understand. For outsiders it may be a bit difficult to find the logic.****
****
Best regards****
Jørgen****
****
****
****
**** ------------------------------
*Fra:* atrt2-bounces@icann.org [mailto:atrt2-bounces@icann.org<atrt2-bounces@icann.org>] *På vegne af *Larisa B. Gurnick *Sendt:* 6. oktober 2013 02:21 *Til:* ATRT2 (atrt2@icann.org) *Emne:* [atrt2] Draft Report - version 1 for review****
Dear Review Team,****
Attached is the Draft Report for your review. It consolidates all the sections circulated by the Review Team thus far. This document is also available on the wiki<https://community.icann.org/download/attachments/43975118/ATRT2%20Report%205...>. ****
** **
Please note the following:****
1. Brian will add text to create a smooth transition from the introduction section to the “templates” or detailed assessment section.*** *
2. Green highlights reference the wiki rows for ease of reference – these will need to be removed before publication.****
3. References to New Recommendations made by ATRT 2 and the underlying “templates” or detailed assessments will need to be mapped out and numbered more clearly.****
4. I took the liberty to provide several suggested edits in the beginning portion of the draft.****
5. Formatting will be standardized later.****
** **
As you have not specified the method that you would like to follow to consolidate edits and revisions, staff suggests that your individual comments and edits be made in the attached document in redline mode (i.e. track changes) and circulated to all. Once you reach a consensus on which changes should be incorporated in the report, staff will make final revisions to the master document. We will coordinate this with Brian. ****
** **
Please let me, Charla or Alice know if you are experiencing any difficulties with this file – it is quite large. ****
** **
Best regards,****
** **
*Larisa B. Gurnick*
Consultant/Senior Director, Organizational Reviews****
Internet Corporation for Assigned Names and Numbers (ICANN)****
larisa.gurnick@icann.org****
310 383-8995****
** **
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
Folks, I have now read and scribbled comments on the draft that Larisa sent out. I have not had time to pay attention to the subsequent messages, so I have likely missed a few key sections. Also, I have not had time to read the appendix devoted to the implementation of the SSR-RT recommendations. I will try to do so on the plane to Los Angeles tomorrow evening, but I wanted to make the deadline for comments this evening. I am also including Karine Perset, Director of Board Support. Once the Board receives the report, we will have a LOT of work to do to evaluate each recommendation, determine our response, and provide formal feedback. To the extent we can organize and plan that work now, we'll be in better shape to complete our side of this when we receive the final report. I am also conscious that I am in the unique position of having three bites at this apple. I am responding now as a member of the team, I will be able to include my comments during the public comment period, and, of course, I will be part of the Board's formal response. Accordingly, I am limiting my comments now to a handful of editorial or factual details that I think should be fixed before the report is released for public comment. I am truly impressed by the enormous amount of work everyone has done, the positive spirit that everyone has brought to the process, and the quite excellent report that is emerging. Thanks! Steve =========================================================================
page 4, Getting the Review Team started with a compile implementation report
Implementation of what? The last ATRT set of recommendations? The recommendations of all of the review teams? I'm not objecting, just suggesting words be added for clarification.
page 9, second para: The implementation discrete action taken by the NomCom…
I did not understand what this sentence was trying to say.
page 10, recommendation 1c in the table, Improve NomCom outreach/PR
I assume "PR" means public relations, but I think this should be spelled out.
page 12, needn't be so obsessed by secrecy and that this was positive
Somewhat unclear wording
ibid, impetuous
Yes, this should be "impetus"
ibid, bullet (a), guaranty
Should be "guarantee," I believe.
page 15, paragraph 5.1, ATRT1 also found that compensation of directors was an issue closely associated with the theme pif developing the ICANN Board's experience and collective skill-set…
Has compensation had any direct bearing on the number or quality of candidates? I am not aware of any data on this? Equally, I am not aware of any data regarding the effect of compensation on the performance of Board members. I think it's appropriate to note that compensation has been put in place, but I don't know what we should say, if anything, about whether it's achieving its intended purpose.
ibid, 5.3 The Board delayed acceptance of Recommendation 5…
This suggests the Board had a choice. Counsel said it was necessary to follow an extended course involving outside assessment. We went down this path as expeditiously as possible. I think the wording here creates the wrong impression, and I will push back vigorously if this assessment is in the public report.
ibid, ATRT2 notes that payments were not offered until August 2012, a significant delay from the date of approval to implementation.
This is factually incorrect, which we have already documented.
page 16, 6.1 Findings of ATRT1
This paragraph is vague. What are the specifics?
page 25, a new ICANN member was hired under a temporary contract…
My understanding is the use of a temporary contract was needed to bring the person on board and it was one part of the process to bring the person in permanently. I would check on the actual sequence and status. The wording here suggests a lack of whole-hearted management support, which does not match my understanding of what actually happened.
ibid, ACIG staff member
What is ACIG?
page 46, 14.7 Hypothesis of problem: While ICANN has a hotline that is meant to serve the whistle blowing activities, evidence does not indicate that this program has been used effectively.
What evidence? Doesn't this paragraph put ATRT2 in the position of making an unsupported charge? ================================================================================================== On Oct 5, 2013, at 8:20 PM, "Larisa B. Gurnick" <larisa.gurnick@icann.org> wrote:
Dear Review Team, Attached is the Draft Report for your review. It consolidates all the sections circulated by the Review Team thus far. This document is also available on the wiki.
Please note the following: 1. Brian will add text to create a smooth transition from the introduction section to the “templates” or detailed assessment section. 2. Green highlights reference the wiki rows for ease of reference – these will need to be removed before publication. 3. References to New Recommendations made by ATRT 2 and the underlying “templates” or detailed assessments will need to be mapped out and numbered more clearly. 4. I took the liberty to provide several suggested edits in the beginning portion of the draft. 5. Formatting will be standardized later.
As you have not specified the method that you would like to follow to consolidate edits and revisions, staff suggests that your individual comments and edits be made in the attached document in redline mode (i.e. track changes) and circulated to all. Once you reach a consensus on which changes should be incorporated in the report, staff will make final revisions to the master document. We will coordinate this with Brian.
Please let me, Charla or Alice know if you are experiencing any difficulties with this file – it is quite large.
Best regards,
Larisa B. Gurnick Consultant/Senior Director, Organizational Reviews Internet Corporation for Assigned Names and Numbers (ICANN) larisa.gurnick@icann.org 310 383-8995
<ATRT2 Report 5 Oct v.1.docx>_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
Folks, Continuing with my comments on the draft Larisa sent out, I have now read the appendix on the SSR-RT recommendations. Also, I have feedback from Karine on the main text. Karine writes:
Having looked rapidly through the report, i saw a number of recommendations involving creating "benchmarks" and "metrics" but no specific example of such metrics, e.g. P 10 "metrics are still needed for evaluating the success of Board improvement efforts". I also see in the draft report that "ICANN has engaged One World Trust (OWT) to assist with the development of Accountability and Transparency Benchmarks and Metrics. The final report is expected by 31 December 2013. Staff will facilitate ATRT 2 input and feedback to OWT. Periodic updates on progress of work will also be shared. The ongoing implementation of Accountability and Transparency Benchmarks and Metrics into ICANN operations will include the incorporation of appropriate benchmarks and metrics into the reporting of implementation progress."
Just to note that it might be difficult until we have the report on the metrics from OWT to respond to the fairly numerous suggestions surrounding metrics, monitoring progress and benchmarks, unless the drafters already have ideas of the types of metrics they foresee us implementing. I will find out more about the specific contract to OWT.
I concur. I'm not sure how much can be done about this before publishing this draft, so I expect we will make this point again during the public comment period and hope for substantive improvement before the final version. With respect to the SSR-RT, as I said before, I am limiting my comments now to a handful of editorial or factual details that I think should be fixed before the report is released for public comment.
Implementability
This word is used as a title for a subsection in response to each of the SSR-RT recommendations. In some cases, the text does assess what we know about whether the recommendation is implementable, but in other cases the text addresses how far along the implementation has progressed. These are different concepts and should be labeled differently.
page 12, There was no comment period or other mechanism for community input associated with the publication of the SSAC Operating Procedures
This wording inappropriately implies there should be a public comment period. The SSAC Operating Procedures is an internal document that captures the processes in effect. It is not a policy document. Publication is done for transparency and comments, if any, will likely be considered, but it was never intended nor would it be appropriate to suggest there is a need for community feedback or approval. ==================================== No other immediate comments on the SSR-RT analysis except that I found many of the SSR-RT recommendations vague, so I think the next time the SSR-RT is convened, it ought to be asked for recommendations that are concrete and measurable. Cheers, Steve ==================================== Folks, I have now read and scribbled comments on the draft that Larisa sent out. I have not had time to pay attention to the subsequent messages, so I have likely missed a few key sections. Also, I have not had time to read the appendix devoted to the implementation of the SSR-RT recommendations. I will try to do so on the plane to Los Angeles tomorrow evening, but I wanted to make the deadline for comments this evening. I am also including Karine Perset, Director of Board Support. Once the Board receives the report, we will have a LOT of work to do to evaluate each recommendation, determine our response, and provide formal feedback. To the extent we can organize and plan that work now, we'll be in better shape to complete our side of this when we receive the final report. I am also conscious that I am in the unique position of having three bites at this apple. I am responding now as a member of the team, I will be able to include my comments during the public comment period, and, of course, I will be part of the Board's formal response. Accordingly, I am limiting my comments now to a handful of editorial or factual details that I think should be fixed before the report is released for public comment. I am truly impressed by the enormous amount of work everyone has done, the positive spirit that everyone has brought to the process, and the quite excellent report that is emerging. Thanks! Steve =========================================================================
page 4, Getting the Review Team started with a compile implementation report
Implementation of what? The last ATRT set of recommendations? The recommendations of all of the review teams? I'm not objecting, just suggesting words be added for clarification.
page 9, second para: The implementation discrete action taken by the NomCom…
I did not understand what this sentence was trying to say.
page 10, recommendation 1c in the table, Improve NomCom outreach/PR
I assume "PR" means public relations, but I think this should be spelled out.
page 12, needn't be so obsessed by secrecy and that this was positive
Somewhat unclear wording
ibid, impetuous
Yes, this should be "impetus"
ibid, bullet (a), guaranty
Should be "guarantee," I believe.
page 15, paragraph 5.1, ATRT1 also found that compensation of directors was an issue closely associated with the theme pif developing the ICANN Board's experience and collective skill-set…
Has compensation had any direct bearing on the number or quality of candidates? I am not aware of any data on this? Equally, I am not aware of any data regarding the effect of compensation on the performance of Board members. I think it's appropriate to note that compensation has been put in place, but I don't know what we should say, if anything, about whether it's achieving its intended purpose.
ibid, 5.3 The Board delayed acceptance of Recommendation 5…
This suggests the Board had a choice. Counsel said it was necessary to follow an extended course involving outside assessment. We went down this path as expeditiously as possible. I think the wording here creates the wrong impression, and I will push back vigorously if this assessment is in the public report.
ibid, ATRT2 notes that payments were not offered until August 2012, a significant delay from the date of approval to implementation.
This is factually incorrect, which we have already documented.
page 16, 6.1 Findings of ATRT1
This paragraph is vague. What are the specifics?
page 25, a new ICANN member was hired under a temporary contract…
My understanding is the use of a temporary contract was needed to bring the person on board and it was one part of the process to bring the person in permanently. I would check on the actual sequence and status. The wording here suggests a lack of whole-hearted management support, which does not match my understanding of what actually happened.
ibid, ACIG staff member
What is ACIG?
page 46, 14.7 Hypothesis of problem: While ICANN has a hotline that is meant to serve the whistle blowing activities, evidence does not indicate that this program has been used effectively.
What evidence? Doesn't this paragraph put ATRT2 in the position of making an unsupported charge? ================================================================================================== On Oct 5, 2013, at 8:20 PM, "Larisa B. Gurnick" <larisa.gurnick@icann.org> wrote:
Dear Review Team, Attached is the Draft Report for your review. It consolidates all the sections circulated by the Review Team thus far. This document is also available on the wiki.
Please note the following: 1. Brian will add text to create a smooth transition from the introduction section to the “templates” or detailed assessment section. 2. Green highlights reference the wiki rows for ease of reference – these will need to be removed before publication. 3. References to New Recommendations made by ATRT 2 and the underlying “templates” or detailed assessments will need to be mapped out and numbered more clearly. 4. I took the liberty to provide several suggested edits in the beginning portion of the draft. 5. Formatting will be standardized later.
As you have not specified the method that you would like to follow to consolidate edits and revisions, staff suggests that your individual comments and edits be made in the attached document in redline mode (i.e. track changes) and circulated to all. Once you reach a consensus on which changes should be incorporated in the report, staff will make final revisions to the master document. We will coordinate this with Brian.
Please let me, Charla or Alice know if you are experiencing any difficulties with this file – it is quite large.
Best regards,
Larisa B. Gurnick Consultant/Senior Director, Organizational Reviews Internet Corporation for Assigned Names and Numbers (ICANN) larisa.gurnick@icann.org 310 383-8995
<ATRT2 Report 5 Oct v.1.docx>_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
On 9 Oct 2013, at 13:04, Steve Crocker wrote:
page 12, There was no comment period or other mechanism for community input associated with the publication of the SSAC Operating Procedures
This wording inappropriately implies there should be a public comment period. The SSAC Operating Procedures is an internal document that captures the processes in effect. It is not a policy document. Publication is done for transparency and comments, if any, will likely be considered, but it was never intended nor would it be appropriate to suggest there is a need for community feedback or approval.
In general, I thought that all SO/AC Operating Procedures go through at least a vetting by the Board and that is preceded by a public comment. I certainly thought this was the case for GNSO Operating Principles. Not sure if this was the case for the ALAC change that just went through, but I thought it was. I don't understand why this would not be the case for SSAC as well. Or should we take this to mean that no SO/AC needs to go through public comment before changing it Operating procedures? Thanks avri
Avri, Speaking as founding chair of SSAC, there wasn't even a requirement for operating procedures for SSAC much less a requirement they be vetted, reviewed or approved by the Board or any other group. As part of my role as chair of SSAC, I initiated the creation of the operating procedures as a pragmatic way of capturing the tidbits of we actually operated. It was specifically not intended to be a set of rules that bound the group to anything. Rather, it was intended as a compendium to help the group remember what it did before. That said, I noticed that once we wrote things down, people tended to interpret the words as binding. Taking your point more broadly, the bylaws given almost no guidance on the structure of SSAC. I didn't study the words associated with the other advisory committees as closely, but I think the situation is similar. The only specific operational requirement is for the Board to approve the membership on SSAC. In the beginning, there weren't any limitations on terms, there was any criteria regarding membership, there weren't any mechanisms for removing someone except, implicitly, to ask the Board to take such an action. I adopted a practice of presenting to the Board nominations and I did so with sufficient documentation to make it clear we had selected people with strong backgrounds. The Board routinely accepted all of our nominations, and when it came time to replace me as chair, the Board chose to ask SSAC to make the choice. SSAC now has three year terms for membership, renewable, and it has an internal process for selecting new members. Either within ATRT2 or through other community processes I can imagine attempting to provide guidance or impose structure on SSAC and/or other advisory committees. If so, I recommend approaching that question directly. Grabbing hold of the operating procedures may be helpful as part of such an effort, but I don't believe it's the right starting point or even the main issue. To press this point a bit further, SSAC has begun to complain that its advice hasn't been followed. As a matter of form, I think that's out of scope, but I also agree and am actively implementing that when they deliver advice it needs to be acknowledged and accounted for. We have wording in our current ATRT2 report that addresses this, which is fine with me. Steve On Oct 9, 2013, at 10:15 AM, Avri Doria <avri@ella.com> wrote:
On 9 Oct 2013, at 13:04, Steve Crocker wrote:
page 12, There was no comment period or other mechanism for community input associated with the publication of the SSAC Operating Procedures
This wording inappropriately implies there should be a public comment period. The SSAC Operating Procedures is an internal document that captures the processes in effect. It is not a policy document. Publication is done for transparency and comments, if any, will likely be considered, but it was never intended nor would it be appropriate to suggest there is a need for community feedback or approval.
In general, I thought that all SO/AC Operating Procedures go through at least a vetting by the Board and that is preceded by a public comment. I certainly thought this was the case for GNSO Operating Principles. Not sure if this was the case for the ALAC change that just went through, but I thought it was. I don't understand why this would not be the case for SSAC as well.
Or should we take this to mean that no SO/AC needs to go through public comment before changing it Operating procedures?
Thanks
avri
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
Hi, I agree that their advice should be considered and think I have argued for that, which arguing that all AC should have their advice treated equally respectfully by the Board. And I would consider SSAC transparency and accountability to the community, at least in terms of process an important consideration. I know they talk about secret stuff and will need to invoke the cloak of secrecy more than most. But I see no reason that their processes should not be accountable to the community. I guess I just don't see the implication of a community review as problematic. Though It may be problematic that this is only an implication. avri On 9 Oct 2013, at 13:35, Steve Crocker wrote:
Avri,
Speaking as founding chair of SSAC, there wasn't even a requirement for operating procedures for SSAC much less a requirement they be vetted, reviewed or approved by the Board or any other group. As part of my role as chair of SSAC, I initiated the creation of the operating procedures as a pragmatic way of capturing the tidbits of we actually operated. It was specifically not intended to be a set of rules that bound the group to anything. Rather, it was intended as a compendium to help the group remember what it did before. That said, I noticed that once we wrote things down, people tended to interpret the words as binding.
Taking your point more broadly, the bylaws given almost no guidance on the structure of SSAC. I didn't study the words associated with the other advisory committees as closely, but I think the situation is similar. The only specific operational requirement is for the Board to approve the membership on SSAC. In the beginning, there weren't any limitations on terms, there was any criteria regarding membership, there weren't any mechanisms for removing someone except, implicitly, to ask the Board to take such an action. I adopted a practice of presenting to the Board nominations and I did so with sufficient documentation to make it clear we had selected people with strong backgrounds. The Board routinely accepted all of our nominations, and when it came time to replace me as chair, the Board chose to ask SSAC to make the choice.
SSAC now has three year terms for membership, renewable, and it has an internal process for selecting new members.
Either within ATRT2 or through other community processes I can imagine attempting to provide guidance or impose structure on SSAC and/or other advisory committees. If so, I recommend approaching that question directly. Grabbing hold of the operating procedures may be helpful as part of such an effort, but I don't believe it's the right starting point or even the main issue.
To press this point a bit further, SSAC has begun to complain that its advice hasn't been followed. As a matter of form, I think that's out of scope, but I also agree and am actively implementing that when they deliver advice it needs to be acknowledged and accounted for. We have wording in our current ATRT2 report that addresses this, which is fine with me.
Steve
On Oct 9, 2013, at 10:15 AM, Avri Doria <avri@ella.com> wrote:
On 9 Oct 2013, at 13:04, Steve Crocker wrote:
page 12, There was no comment period or other mechanism for community input associated with the publication of the SSAC Operating Procedures
This wording inappropriately implies there should be a public comment period. The SSAC Operating Procedures is an internal document that captures the processes in effect. It is not a policy document. Publication is done for transparency and comments, if any, will likely be considered, but it was never intended nor would it be appropriate to suggest there is a need for community feedback or approval.
In general, I thought that all SO/AC Operating Procedures go through at least a vetting by the Board and that is preceded by a public comment. I certainly thought this was the case for GNSO Operating Principles. Not sure if this was the case for the ALAC change that just went through, but I thought it was. I don't understand why this would not be the case for SSAC as well.
Or should we take this to mean that no SO/AC needs to go through public comment before changing it Operating procedures?
Thanks
avri
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
On Oct 9, 2013, at 10:47 AM, Avri Doria <avri@ella.com> wrote:
Hi,
I agree that their advice should be considered and think I have argued for that, which arguing that all AC should have their advice treated equally respectfully by the Board.
And I would consider SSAC transparency and accountability to the community, at least in terms of process an important consideration. I know they talk about secret stuff and will need to invoke the cloak of secrecy more than most. But I see no reason that their processes should not be accountable to the community.
They don't actually talk about secret stuff, which I think is a limitation. I've been privy to information about the interior of ICANN that I would have loved to have SSAC look at, but the SSAC folks didn't seem interested in engaging nor in setting up procedures for adhering to the confidentiality requirements.
I guess I just don't see the implication of a community review as problematic. Though It may be problematic that this is only an implication.
Let me suggest an unintended consequence of your perspective. By focusing on whether the SSAC processes meet community standards, you're implicitly adding weight to the "who" and "how" of SSAC's output, and that implicitly undermines the "what." The strength and utility of SSAC's work must, in my view, be based on the quality of the advice they provide and not their reputation or stature. If "SSAC said X" becomes the meme and creates an assumption that therefore X must be done, it lays the foundation for SSAC, like any other group, to act as if they have authority instead of only credibility. That's a very slippery slope, which I think is not the way to go. Steve
avri
On 9 Oct 2013, at 13:35, Steve Crocker wrote:
Avri,
Speaking as founding chair of SSAC, there wasn't even a requirement for operating procedures for SSAC much less a requirement they be vetted, reviewed or approved by the Board or any other group. As part of my role as chair of SSAC, I initiated the creation of the operating procedures as a pragmatic way of capturing the tidbits of we actually operated. It was specifically not intended to be a set of rules that bound the group to anything. Rather, it was intended as a compendium to help the group remember what it did before. That said, I noticed that once we wrote things down, people tended to interpret the words as binding.
Taking your point more broadly, the bylaws given almost no guidance on the structure of SSAC. I didn't study the words associated with the other advisory committees as closely, but I think the situation is similar. The only specific operational requirement is for the Board to approve the membership on SSAC. In the beginning, there weren't any limitations on terms, there was any criteria regarding membership, there weren't any mechanisms for removing someone except, implicitly, to ask the Board to take such an action. I adopted a practice of presenting to the Board nominations and I did so with sufficient documentation to make it clear we had selected people with strong backgrounds. The Board routinely accepted all of our nominations, and when it came time to replace me as chair, the Board chose to ask SSAC to make the choice.
SSAC now has three year terms for membership, renewable, and it has an internal process for selecting new members.
Either within ATRT2 or through other community processes I can imagine attempting to provide guidance or impose structure on SSAC and/or other advisory committees. If so, I recommend approaching that question directly. Grabbing hold of the operating procedures may be helpful as part of such an effort, but I don't believe it's the right starting point or even the main issue.
To press this point a bit further, SSAC has begun to complain that its advice hasn't been followed. As a matter of form, I think that's out of scope, but I also agree and am actively implementing that when they deliver advice it needs to be acknowledged and accounted for. We have wording in our current ATRT2 report that addresses this, which is fine with me.
Steve
On Oct 9, 2013, at 10:15 AM, Avri Doria <avri@ella.com> wrote:
On 9 Oct 2013, at 13:04, Steve Crocker wrote:
page 12, There was no comment period or other mechanism for community input associated with the publication of the SSAC Operating Procedures
This wording inappropriately implies there should be a public comment period. The SSAC Operating Procedures is an internal document that captures the processes in effect. It is not a policy document. Publication is done for transparency and comments, if any, will likely be considered, but it was never intended nor would it be appropriate to suggest there is a need for community feedback or approval.
In general, I thought that all SO/AC Operating Procedures go through at least a vetting by the Board and that is preceded by a public comment. I certainly thought this was the case for GNSO Operating Principles. Not sure if this was the case for the ALAC change that just went through, but I thought it was. I don't understand why this would not be the case for SSAC as well.
Or should we take this to mean that no SO/AC needs to go through public comment before changing it Operating procedures?
Thanks
avri
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
Let me suggest an unintended consequence of your perspective. By focusing on whether the SSAC processes meet community standards, you're implicitly adding weight to the "who" and "how" of SSAC's output, and that implicitly undermines the "what." The strength and utility of SSAC's work must, in my view, be based on the quality of the advice they provide and not their reputation or stature. If "SSAC said X" becomes the meme and creates an assumption that therefore X must be done, it lays the foundation for SSAC, like any other group, to act as if they have authority instead of only credibility. That's a very slippery slope, which I think is not the way to go. Steve
Good point raised by Steve. Ageed! demi On 10/09/2013 03:12 PM, Steve Crocker wrote:
On Oct 9, 2013, at 10:47 AM, Avri Doria <avri@ella.com> wrote:
Hi,
I agree that their advice should be considered and think I have argued for that, which arguing that all AC should have their advice treated equally respectfully by the Board.
And I would consider SSAC transparency and accountability to the community, at least in terms of process an important consideration. I know they talk about secret stuff and will need to invoke the cloak of secrecy more than most. But I see no reason that their processes should not be accountable to the community. They don't actually talk about secret stuff, which I think is a limitation. I've been privy to information about the interior of ICANN that I would have loved to have SSAC look at, but the SSAC folks didn't seem interested in engaging nor in setting up procedures for adhering to the confidentiality requirements.
I guess I just don't see the implication of a community review as problematic. Though It may be problematic that this is only an implication. Let me suggest an unintended consequence of your perspective. By focusing on whether the SSAC processes meet community standards, you're implicitly adding weight to the "who" and "how" of SSAC's output, and that implicitly undermines the "what." The strength and utility of SSAC's work must, in my view, be based on the quality of the advice they provide and not their reputation or stature. If "SSAC said X" becomes the meme and creates an assumption that therefore X must be done, it lays the foundation for SSAC, like any other group, to act as if they have authority instead of only credibility. That's a very slippery slope, which I think is not the way to go.
Steve
avri
On 9 Oct 2013, at 13:35, Steve Crocker wrote:
Avri,
Speaking as founding chair of SSAC, there wasn't even a requirement for operating procedures for SSAC much less a requirement they be vetted, reviewed or approved by the Board or any other group. As part of my role as chair of SSAC, I initiated the creation of the operating procedures as a pragmatic way of capturing the tidbits of we actually operated. It was specifically not intended to be a set of rules that bound the group to anything. Rather, it was intended as a compendium to help the group remember what it did before. That said, I noticed that once we wrote things down, people tended to interpret the words as binding.
Taking your point more broadly, the bylaws given almost no guidance on the structure of SSAC. I didn't study the words associated with the other advisory committees as closely, but I think the situation is similar. The only specific operational requirement is for the Board to approve the membership on SSAC. In the beginning, there weren't any limitations on terms, there was any criteria regarding membership, there weren't any mechanisms for removing someone except, implicitly, to ask the Board to take such an action. I adopted a practice of presenting to the Board nominations and I did so with sufficient documentation to make it clear we had selected people with strong backgrounds. The Board routinely accepted all of our nominations, and when it came time to replace me as chair, the Board chose to ask SSAC to make the choice.
SSAC now has three year terms for membership, renewable, and it has an internal process for selecting new members.
Either within ATRT2 or through other community processes I can imagine attempting to provide guidance or impose structure on SSAC and/or other advisory committees. If so, I recommend approaching that question directly. Grabbing hold of the operating procedures may be helpful as part of such an effort, but I don't believe it's the right starting point or even the main issue.
To press this point a bit further, SSAC has begun to complain that its advice hasn't been followed. As a matter of form, I think that's out of scope, but I also agree and am actively implementing that when they deliver advice it needs to be acknowledged and accounted for. We have wording in our current ATRT2 report that addresses this, which is fine with me.
Steve
On Oct 9, 2013, at 10:15 AM, Avri Doria <avri@ella.com> wrote:
On 9 Oct 2013, at 13:04, Steve Crocker wrote:
page 12, There was no comment period or other mechanism for community input associated with the publication of the SSAC Operating Procedures This wording inappropriately implies there should be a public comment period. The SSAC Operating Procedures is an internal document that captures the processes in effect. It is not a policy document. Publication is done for transparency and comments, if any, will likely be considered, but it was never intended nor would it be appropriate to suggest there is a need for community feedback or approval.
In general, I thought that all SO/AC Operating Procedures go through at least a vetting by the Board and that is preceded by a public comment. I certainly thought this was the case for GNSO Operating Principles. Not sure if this was the case for the ALAC change that just went through, but I thought it was. I don't understand why this would not be the case for SSAC as well.
Or should we take this to mean that no SO/AC needs to go through public comment before changing it Operating procedures?
Thanks
avri
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
Hi, Ok, I guess I have to accept that SSAC, like GAC is special and is not subject to the same considerations as the rest of the SO/AC. Makes no sense to me. I came to grudgingly accept the special sensitivities of governments to being treated equally to other SO/AC. I guess this is just one more step in enumerating the groups that are somehow special and thus beyond accountability and transparency. But if this is the decision of the Board, what am i going to do? I will give up on this unless I see that someone else in this group sees the world as I do. I think this is a huge problem, but if I am alone, I will not go to war over it within the ATRT2. avri On 9 Oct 2013, at 14:21, Demi Getschko wrote:
Let me suggest an unintended consequence of your perspective. By focusing on whether the SSAC processes meet community standards, you're implicitly adding weight to the "who" and "how" of SSAC's output, and that implicitly undermines the "what." The strength and utility of SSAC's work must, in my view, be based on the quality of the advice they provide and not their reputation or stature. If "SSAC said X" becomes the meme and creates an assumption that therefore X must be done, it lays the foundation for SSAC, like any other group, to act as if they have authority instead of only credibility. That's a very slippery slope, which I think is not the way to go. Steve
Good point raised by Steve. Ageed!
demi
On 10/09/2013 03:12 PM, Steve Crocker wrote:
On Oct 9, 2013, at 10:47 AM, Avri Doria <avri@ella.com> wrote:
Hi,
I agree that their advice should be considered and think I have argued for that, which arguing that all AC should have their advice treated equally respectfully by the Board.
And I would consider SSAC transparency and accountability to the community, at least in terms of process an important consideration. I know they talk about secret stuff and will need to invoke the cloak of secrecy more than most. But I see no reason that their processes should not be accountable to the community. They don't actually talk about secret stuff, which I think is a limitation. I've been privy to information about the interior of ICANN that I would have loved to have SSAC look at, but the SSAC folks didn't seem interested in engaging nor in setting up procedures for adhering to the confidentiality requirements.
I guess I just don't see the implication of a community review as problematic. Though It may be problematic that this is only an implication. Let me suggest an unintended consequence of your perspective. By focusing on whether the SSAC processes meet community standards, you're implicitly adding weight to the "who" and "how" of SSAC's output, and that implicitly undermines the "what." The strength and utility of SSAC's work must, in my view, be based on the quality of the advice they provide and not their reputation or stature. If "SSAC said X" becomes the meme and creates an assumption that therefore X must be done, it lays the foundation for SSAC, like any other group, to act as if they have authority instead of only credibility. That's a very slippery slope, which I think is not the way to go.
Steve
avri
On 9 Oct 2013, at 13:35, Steve Crocker wrote:
Avri,
Speaking as founding chair of SSAC, there wasn't even a requirement for operating procedures for SSAC much less a requirement they be vetted, reviewed or approved by the Board or any other group. As part of my role as chair of SSAC, I initiated the creation of the operating procedures as a pragmatic way of capturing the tidbits of we actually operated. It was specifically not intended to be a set of rules that bound the group to anything. Rather, it was intended as a compendium to help the group remember what it did before. That said, I noticed that once we wrote things down, people tended to interpret the words as binding.
Taking your point more broadly, the bylaws given almost no guidance on the structure of SSAC. I didn't study the words associated with the other advisory committees as closely, but I think the situation is similar. The only specific operational requirement is for the Board to approve the membership on SSAC. In the beginning, there weren't any limitations on terms, there was any criteria regarding membership, there weren't any mechanisms for removing someone except, implicitly, to ask the Board to take such an action. I adopted a practice of presenting to the Board nominations and I did so with sufficient documentation to make it clear we had selected people with strong backgrounds. The Board routinely accepted all of our nominations, and when it came time to replace me as chair, the Board chose to ask SSAC to make the choice.
SSAC now has three year terms for membership, renewable, and it has an internal process for selecting new members.
Either within ATRT2 or through other community processes I can imagine attempting to provide guidance or impose structure on SSAC and/or other advisory committees. If so, I recommend approaching that question directly. Grabbing hold of the operating procedures may be helpful as part of such an effort, but I don't believe it's the right starting point or even the main issue.
To press this point a bit further, SSAC has begun to complain that its advice hasn't been followed. As a matter of form, I think that's out of scope, but I also agree and am actively implementing that when they deliver advice it needs to be acknowledged and accounted for. We have wording in our current ATRT2 report that addresses this, which is fine with me.
Steve
On Oct 9, 2013, at 10:15 AM, Avri Doria <avri@ella.com> wrote:
On 9 Oct 2013, at 13:04, Steve Crocker wrote:
> page 12, There was no comment period or other mechanism for community input associated with the publication of the SSAC Operating Procedures This wording inappropriately implies there should be a public comment period. The SSAC Operating Procedures is an internal document that captures the processes in effect. It is not a policy document. Publication is done for transparency and comments, if any, will likely be considered, but it was never intended nor would it be appropriate to suggest there is a need for community feedback or approval.
In general, I thought that all SO/AC Operating Procedures go through at least a vetting by the Board and that is preceded by a public comment. I certainly thought this was the case for GNSO Operating Principles. Not sure if this was the case for the ALAC change that just went through, but I thought it was. I don't understand why this would not be the case for SSAC as well.
Or should we take this to mean that no SO/AC needs to go through public comment before changing it Operating procedures?
Thanks
avri
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
Not good enough. This is an important point and not one where it makes sense to throw up your hands and say you don't understand. That's code for "I disagree but I'm overruled" and it leaves you in a position to continue to criticize without closure. Let me suggest the essence here has two elements. First, there is an intentional structural difference between SOs and ACs. SOs represent constituencies and have formal power. Decisions, in the form of policy adoptions, by SOs have authority. The authority is not absolute because the Board can, in principle, refuse to accept their policies, but the bar is very high and not often or easily exercised. The ACs are, in principle, intended to provide advice. However, the second salient element here is the ACs are not a uniform group. There is more disparity among the ACs than there is among the SOs, even though there is quite a bit of disparity across the SOs. The GAC, in particular, feels it has a certain level of authority, and in that respect has some characteristics of an SO. SSAC is at the other end of the spectrum. No defined constituency and no authority. No predefined criteria for membership. They make an effort to have members from all parts of the world, to have some women to balance the usual all male club, to have people who have background or connection with registrars, registries, address registries, root operators, security researchers, etc., etc., but there aren't any formal rules. If you start with the presumption that an advisory committee must meet the same criteria as, say, the Board or even the SOs, then you're focusing on process and not results, and you're attempting to add cost and criticism without any indication that it's needed. In my view, the time to look at the process is after the results have become poor or there are substantial complaints about how people are treated. On the other hand, looking at their effectiveness and relevance is always appropriate. Steve On Oct 9, 2013, at 12:12 PM, Avri Doria <avri@ella.com> wrote:
Hi,
Ok, I guess I have to accept that SSAC, like GAC is special and is not subject to the same considerations as the rest of the SO/AC.
Makes no sense to me. I came to grudgingly accept the special sensitivities of governments to being treated equally to other SO/AC. I guess this is just one more step in enumerating the groups that are somehow special and thus beyond accountability and transparency.
But if this is the decision of the Board, what am i going to do? I will give up on this unless I see that someone else in this group sees the world as I do. I think this is a huge problem, but if I am alone, I will not go to war over it within the ATRT2.
avri
On 9 Oct 2013, at 14:21, Demi Getschko wrote:
Let me suggest an unintended consequence of your perspective. By focusing on whether the SSAC processes meet community standards, you're implicitly adding weight to the "who" and "how" of SSAC's output, and that implicitly undermines the "what." The strength and utility of SSAC's work must, in my view, be based on the quality of the advice they provide and not their reputation or stature. If "SSAC said X" becomes the meme and creates an assumption that therefore X must be done, it lays the foundation for SSAC, like any other group, to act as if they have authority instead of only credibility. That's a very slippery slope, which I think is not the way to go. Steve
Good point raised by Steve. Ageed!
demi
On 10/09/2013 03:12 PM, Steve Crocker wrote:
On Oct 9, 2013, at 10:47 AM, Avri Doria <avri@ella.com> wrote:
Hi,
I agree that their advice should be considered and think I have argued for that, which arguing that all AC should have their advice treated equally respectfully by the Board.
And I would consider SSAC transparency and accountability to the community, at least in terms of process an important consideration. I know they talk about secret stuff and will need to invoke the cloak of secrecy more than most. But I see no reason that their processes should not be accountable to the community. They don't actually talk about secret stuff, which I think is a limitation. I've been privy to information about the interior of ICANN that I would have loved to have SSAC look at, but the SSAC folks didn't seem interested in engaging nor in setting up procedures for adhering to the confidentiality requirements.
I guess I just don't see the implication of a community review as problematic. Though It may be problematic that this is only an implication. Let me suggest an unintended consequence of your perspective. By focusing on whether the SSAC processes meet community standards, you're implicitly adding weight to the "who" and "how" of SSAC's output, and that implicitly undermines the "what." The strength and utility of SSAC's work must, in my view, be based on the quality of the advice they provide and not their reputation or stature. If "SSAC said X" becomes the meme and creates an assumption that therefore X must be done, it lays the foundation for SSAC, like any other group, to act as if they have authority instead of only credibility. That's a very slippery slope, which I think is not the way to go.
Steve
avri
On 9 Oct 2013, at 13:35, Steve Crocker wrote:
Avri,
Speaking as founding chair of SSAC, there wasn't even a requirement for operating procedures for SSAC much less a requirement they be vetted, reviewed or approved by the Board or any other group. As part of my role as chair of SSAC, I initiated the creation of the operating procedures as a pragmatic way of capturing the tidbits of we actually operated. It was specifically not intended to be a set of rules that bound the group to anything. Rather, it was intended as a compendium to help the group remember what it did before. That said, I noticed that once we wrote things down, people tended to interpret the words as binding.
Taking your point more broadly, the bylaws given almost no guidance on the structure of SSAC. I didn't study the words associated with the other advisory committees as closely, but I think the situation is similar. The only specific operational requirement is for the Board to approve the membership on SSAC. In the beginning, there weren't any limitations on terms, there was any criteria regarding membership, there weren't any mechanisms for removing someone except, implicitly, to ask the Board to take such an action. I adopted a practice of presenting to the Board nominations and I did so with sufficient documentation to make it clear we had selected people with strong backgrounds. The Board routinely accepted all of our nominations, and when it came time to replace me as chair, the Board chose to ask SSAC to make the choice.
SSAC now has three year terms for membership, renewable, and it has an internal process for selecting new members.
Either within ATRT2 or through other community processes I can imagine attempting to provide guidance or impose structure on SSAC and/or other advisory committees. If so, I recommend approaching that question directly. Grabbing hold of the operating procedures may be helpful as part of such an effort, but I don't believe it's the right starting point or even the main issue.
To press this point a bit further, SSAC has begun to complain that its advice hasn't been followed. As a matter of form, I think that's out of scope, but I also agree and am actively implementing that when they deliver advice it needs to be acknowledged and accounted for. We have wording in our current ATRT2 report that addresses this, which is fine with me.
Steve
On Oct 9, 2013, at 10:15 AM, Avri Doria <avri@ella.com> wrote:
On 9 Oct 2013, at 13:04, Steve Crocker wrote:
>> page 12, There was no comment period or other mechanism for community input associated with the publication of the SSAC Operating Procedures > This wording inappropriately implies there should be a public comment period. The SSAC Operating Procedures is an internal document that captures the processes in effect. It is not a policy document. Publication is done for transparency and comments, if any, will likely be considered, but it was never intended nor would it be appropriate to suggest there is a need for community feedback or approval. >
In general, I thought that all SO/AC Operating Procedures go through at least a vetting by the Board and that is preceded by a public comment. I certainly thought this was the case for GNSO Operating Principles. Not sure if this was the case for the ALAC change that just went through, but I thought it was. I don't understand why this would not be the case for SSAC as well.
Or should we take this to mean that no SO/AC needs to go through public comment before changing it Operating procedures?
Thanks
avri
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
Hi, It is not specific selection criteria I am arguing for. I apologize if anything I wrote gave that impression. It is the ways they operate that I think need to be subject to accountability and transparency. They can be as in a box of their own making as they like, as long as the construction of the box is transparent and the rules by which they function are transparent and are open to public review and comment. I tend to think that most of what they discuss should also be transparent, and subject to the same notions of default transparency, but that is not the topic of this conversation. So pick the right people by whatever criteria makes sense for the job at hand - all ACs do. But let us know how it is done and let us comment on that. Let us know what the processes are and let us comment on them when they change. Let us know how we can provide input and comment on those means. Let us know what we can know about what happens in this select group. I can accept it is a select group of wizards talking all sorts of talk we others may never understand. I personally don't accept that they get to do it in secret according to rules they make up without any comment from the rest of the community. As for criticizing without closure that is a right we all have when we lose a discussion. But in terms of ATRT2, this is a last minute discussion that is probably making those working on getting the doc out stressed. In terms of the issue itself, I beleive I made my point, I beleive you understood it. From the silence I beleive I am alone in my objection to your change request. That seems to be rough consensus of sorts - and in the face of rough consensus, I have no choice but to withdraw. I am probably among the closest to holding absolutist notions on transparency. I come from the GNSO where other than perhaps ALAC, we have the most transparent AC/SO in the community. And I come from the NCSG where I beleive we have the most transparent SG in the GNSO. I think all SO/AC should do all they can to approach the same degree of maximal transparency, and I find [GAC and] SSAC exceptionalism disturbing. But that isn't one of the issues we are tackling in this draft or even in this rev of the ATRT - So I am not going to try and force the issue. But yes, I will focus special personal scrutiny on the SSAC from this point on. During the meeting we had with them, it was quite a revelation to watch the group dynamics and see that the AC was not as I had always assumed it to be from outside the block box. I am grateful that the ATRT2 meeting with them afforded me this glimpse, and that our records include this glimpse for all who may be interested. With the SSAC and its contribution to the current massive confusion the community is going through on the safety of new gTLDs, I do think that in the future the transparency and accountability of the SSAC are going to be very important community topics. avri On 9 Oct 2013, at 15:35, Steve Crocker wrote:
Not good enough. This is an important point and not one where it makes sense to throw up your hands and say you don't understand. That's code for "I disagree but I'm overruled" and it leaves you in a position to continue to criticize without closure.
Let me suggest the essence here has two elements. First, there is an intentional structural difference between SOs and ACs. SOs represent constituencies and have formal power. Decisions, in the form of policy adoptions, by SOs have authority. The authority is not absolute because the Board can, in principle, refuse to accept their policies, but the bar is very high and not often or easily exercised.
The ACs are, in principle, intended to provide advice. However, the second salient element here is the ACs are not a uniform group. There is more disparity among the ACs than there is among the SOs, even though there is quite a bit of disparity across the SOs. The GAC, in particular, feels it has a certain level of authority, and in that respect has some characteristics of an SO.
SSAC is at the other end of the spectrum. No defined constituency and no authority. No predefined criteria for membership. They make an effort to have members from all parts of the world, to have some women to balance the usual all male club, to have people who have background or connection with registrars, registries, address registries, root operators, security researchers, etc., etc., but there aren't any formal rules.
If you start with the presumption that an advisory committee must meet the same criteria as, say, the Board or even the SOs, then you're focusing on process and not results, and you're attempting to add cost and criticism without any indication that it's needed. In my view, the time to look at the process is after the results have become poor or there are substantial complaints about how people are treated. On the other hand, looking at their effectiveness and relevance is always appropriate.
Steve
On Oct 9, 2013, at 12:12 PM, Avri Doria <avri@ella.com> wrote:
Hi,
Ok, I guess I have to accept that SSAC, like GAC is special and is not subject to the same considerations as the rest of the SO/AC.
Makes no sense to me. I came to grudgingly accept the special sensitivities of governments to being treated equally to other SO/AC. I guess this is just one more step in enumerating the groups that are somehow special and thus beyond accountability and transparency.
But if this is the decision of the Board, what am i going to do? I will give up on this unless I see that someone else in this group sees the world as I do. I think this is a huge problem, but if I am alone, I will not go to war over it within the ATRT2.
avri
On 9 Oct 2013, at 14:21, Demi Getschko wrote:
Let me suggest an unintended consequence of your perspective. By focusing on whether the SSAC processes meet community standards, you're implicitly adding weight to the "who" and "how" of SSAC's output, and that implicitly undermines the "what." The strength and utility of SSAC's work must, in my view, be based on the quality of the advice they provide and not their reputation or stature. If "SSAC said X" becomes the meme and creates an assumption that therefore X must be done, it lays the foundation for SSAC, like any other group, to act as if they have authority instead of only credibility. That's a very slippery slope, which I think is not the way to go. Steve
Good point raised by Steve. Ageed!
demi
On 10/09/2013 03:12 PM, Steve Crocker wrote:
On Oct 9, 2013, at 10:47 AM, Avri Doria <avri@ella.com> wrote:
Hi,
I agree that their advice should be considered and think I have argued for that, which arguing that all AC should have their advice treated equally respectfully by the Board.
And I would consider SSAC transparency and accountability to the community, at least in terms of process an important consideration. I know they talk about secret stuff and will need to invoke the cloak of secrecy more than most. But I see no reason that their processes should not be accountable to the community. They don't actually talk about secret stuff, which I think is a limitation. I've been privy to information about the interior of ICANN that I would have loved to have SSAC look at, but the SSAC folks didn't seem interested in engaging nor in setting up procedures for adhering to the confidentiality requirements.
I guess I just don't see the implication of a community review as problematic. Though It may be problematic that this is only an implication. Let me suggest an unintended consequence of your perspective. By focusing on whether the SSAC processes meet community standards, you're implicitly adding weight to the "who" and "how" of SSAC's output, and that implicitly undermines the "what." The strength and utility of SSAC's work must, in my view, be based on the quality of the advice they provide and not their reputation or stature. If "SSAC said X" becomes the meme and creates an assumption that therefore X must be done, it lays the foundation for SSAC, like any other group, to act as if they have authority instead of only credibility. That's a very slippery slope, which I think is not the way to go.
Steve
avri
On 9 Oct 2013, at 13:35, Steve Crocker wrote:
Avri,
Speaking as founding chair of SSAC, there wasn't even a requirement for operating procedures for SSAC much less a requirement they be vetted, reviewed or approved by the Board or any other group. As part of my role as chair of SSAC, I initiated the creation of the operating procedures as a pragmatic way of capturing the tidbits of we actually operated. It was specifically not intended to be a set of rules that bound the group to anything. Rather, it was intended as a compendium to help the group remember what it did before. That said, I noticed that once we wrote things down, people tended to interpret the words as binding.
Taking your point more broadly, the bylaws given almost no guidance on the structure of SSAC. I didn't study the words associated with the other advisory committees as closely, but I think the situation is similar. The only specific operational requirement is for the Board to approve the membership on SSAC. In the beginning, there weren't any limitations on terms, there was any criteria regarding membership, there weren't any mechanisms for removing someone except, implicitly, to ask the Board to take such an action. I adopted a practice of presenting to the Board nominations and I did so with sufficient documentation to make it clear we had selected people with strong backgrounds. The Board routinely accepted all of our nominations, and when it came time to replace me as chair, the Board chose to ask SSAC to make the choice.
SSAC now has three year terms for membership, renewable, and it has an internal process for selecting new members.
Either within ATRT2 or through other community processes I can imagine attempting to provide guidance or impose structure on SSAC and/or other advisory committees. If so, I recommend approaching that question directly. Grabbing hold of the operating procedures may be helpful as part of such an effort, but I don't believe it's the right starting point or even the main issue.
To press this point a bit further, SSAC has begun to complain that its advice hasn't been followed. As a matter of form, I think that's out of scope, but I also agree and am actively implementing that when they deliver advice it needs to be acknowledged and accounted for. We have wording in our current ATRT2 report that addresses this, which is fine with me.
Steve
On Oct 9, 2013, at 10:15 AM, Avri Doria <avri@ella.com> wrote:
> On 9 Oct 2013, at 13:04, Steve Crocker wrote: > >>> page 12, There was no comment period or other mechanism for community input associated with the publication of the SSAC Operating Procedures >> This wording inappropriately implies there should be a public comment period. The SSAC Operating Procedures is an internal document that captures the processes in effect. It is not a policy document. Publication is done for transparency and comments, if any, will likely be considered, but it was never intended nor would it be appropriate to suggest there is a need for community feedback or approval. >> > > In general, I thought that all SO/AC Operating Procedures go through at least a vetting by the Board and that is preceded by a public comment. I certainly thought this was the case for GNSO Operating Principles. Not sure if this was the case for the ALAC change that just went through, but I thought it was. I don't understand why this would not be the case for SSAC as well. > > Or should we take this to mean that no SO/AC needs to go through public comment before changing it Operating procedures? > > Thanks > > avri > > _______________________________________________ > atrt2 mailing list > atrt2@icann.org > https://mm.icann.org/mailman/listinfo/atrt2 _______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
I would argue that SSAC's processes are documented and transparent. Further, it's always possible to comment. I think the key difference in our views is whether there needs to be a formal comment period with the implication that SSAC would then be obliged to meet some external standard for how it does its work. That said, I agree with you that we have taken this as far as is useful at this point. Thanks, Steve On Oct 9, 2013, at 1:38 PM, Avri Doria <avri@ella.com> wrote:
Hi,
It is not specific selection criteria I am arguing for. I apologize if anything I wrote gave that impression.
It is the ways they operate that I think need to be subject to accountability and transparency. They can be as in a box of their own making as they like, as long as the construction of the box is transparent and the rules by which they function are transparent and are open to public review and comment. I tend to think that most of what they discuss should also be transparent, and subject to the same notions of default transparency, but that is not the topic of this conversation.
So pick the right people by whatever criteria makes sense for the job at hand - all ACs do. But let us know how it is done and let us comment on that. Let us know what the processes are and let us comment on them when they change. Let us know how we can provide input and comment on those means. Let us know what we can know about what happens in this select group.
I can accept it is a select group of wizards talking all sorts of talk we others may never understand. I personally don't accept that they get to do it in secret according to rules they make up without any comment from the rest of the community.
As for criticizing without closure that is a right we all have when we lose a discussion. But in terms of ATRT2, this is a last minute discussion that is probably making those working on getting the doc out stressed. In terms of the issue itself, I beleive I made my point, I beleive you understood it. From the silence I beleive I am alone in my objection to your change request. That seems to be rough consensus of sorts - and in the face of rough consensus, I have no choice but to withdraw.
I am probably among the closest to holding absolutist notions on transparency. I come from the GNSO where other than perhaps ALAC, we have the most transparent AC/SO in the community. And I come from the NCSG where I beleive we have the most transparent SG in the GNSO. I think all SO/AC should do all they can to approach the same degree of maximal transparency, and I find [GAC and] SSAC exceptionalism disturbing.
But that isn't one of the issues we are tackling in this draft or even in this rev of the ATRT - So I am not going to try and force the issue. But yes, I will focus special personal scrutiny on the SSAC from this point on. During the meeting we had with them, it was quite a revelation to watch the group dynamics and see that the AC was not as I had always assumed it to be from outside the block box. I am grateful that the ATRT2 meeting with them afforded me this glimpse, and that our records include this glimpse for all who may be interested. With the SSAC and its contribution to the current massive confusion the community is going through on the safety of new gTLDs, I do think that in the future the transparency and accountability of the SSAC are going to be very important community topics.
avri
On 9 Oct 2013, at 15:35, Steve Crocker wrote:
Not good enough. This is an important point and not one where it makes sense to throw up your hands and say you don't understand. That's code for "I disagree but I'm overruled" and it leaves you in a position to continue to criticize without closure.
Let me suggest the essence here has two elements. First, there is an intentional structural difference between SOs and ACs. SOs represent constituencies and have formal power. Decisions, in the form of policy adoptions, by SOs have authority. The authority is not absolute because the Board can, in principle, refuse to accept their policies, but the bar is very high and not often or easily exercised.
The ACs are, in principle, intended to provide advice. However, the second salient element here is the ACs are not a uniform group. There is more disparity among the ACs than there is among the SOs, even though there is quite a bit of disparity across the SOs. The GAC, in particular, feels it has a certain level of authority, and in that respect has some characteristics of an SO.
SSAC is at the other end of the spectrum. No defined constituency and no authority. No predefined criteria for membership. They make an effort to have members from all parts of the world, to have some women to balance the usual all male club, to have people who have background or connection with registrars, registries, address registries, root operators, security researchers, etc., etc., but there aren't any formal rules.
If you start with the presumption that an advisory committee must meet the same criteria as, say, the Board or even the SOs, then you're focusing on process and not results, and you're attempting to add cost and criticism without any indication that it's needed. In my view, the time to look at the process is after the results have become poor or there are substantial complaints about how people are treated. On the other hand, looking at their effectiveness and relevance is always appropriate.
Steve
On Oct 9, 2013, at 12:12 PM, Avri Doria <avri@ella.com> wrote:
Hi,
Ok, I guess I have to accept that SSAC, like GAC is special and is not subject to the same considerations as the rest of the SO/AC.
Makes no sense to me. I came to grudgingly accept the special sensitivities of governments to being treated equally to other SO/AC. I guess this is just one more step in enumerating the groups that are somehow special and thus beyond accountability and transparency.
But if this is the decision of the Board, what am i going to do? I will give up on this unless I see that someone else in this group sees the world as I do. I think this is a huge problem, but if I am alone, I will not go to war over it within the ATRT2.
avri
On 9 Oct 2013, at 14:21, Demi Getschko wrote:
Let me suggest an unintended consequence of your perspective. By focusing on whether the SSAC processes meet community standards, you're implicitly adding weight to the "who" and "how" of SSAC's output, and that implicitly undermines the "what." The strength and utility of SSAC's work must, in my view, be based on the quality of the advice they provide and not their reputation or stature. If "SSAC said X" becomes the meme and creates an assumption that therefore X must be done, it lays the foundation for SSAC, like any other group, to act as if they have authority instead of only credibility. That's a very slippery slope, which I think is not the way to go. Steve
Good point raised by Steve. Ageed!
demi
On 10/09/2013 03:12 PM, Steve Crocker wrote:
On Oct 9, 2013, at 10:47 AM, Avri Doria <avri@ella.com> wrote:
Hi,
I agree that their advice should be considered and think I have argued for that, which arguing that all AC should have their advice treated equally respectfully by the Board.
And I would consider SSAC transparency and accountability to the community, at least in terms of process an important consideration. I know they talk about secret stuff and will need to invoke the cloak of secrecy more than most. But I see no reason that their processes should not be accountable to the community. They don't actually talk about secret stuff, which I think is a limitation. I've been privy to information about the interior of ICANN that I would have loved to have SSAC look at, but the SSAC folks didn't seem interested in engaging nor in setting up procedures for adhering to the confidentiality requirements.
I guess I just don't see the implication of a community review as problematic. Though It may be problematic that this is only an implication. Let me suggest an unintended consequence of your perspective. By focusing on whether the SSAC processes meet community standards, you're implicitly adding weight to the "who" and "how" of SSAC's output, and that implicitly undermines the "what." The strength and utility of SSAC's work must, in my view, be based on the quality of the advice they provide and not their reputation or stature. If "SSAC said X" becomes the meme and creates an assumption that therefore X must be done, it lays the foundation for SSAC, like any other group, to act as if they have authority instead of only credibility. That's a very slippery slope, which I think is not the way to go.
Steve
avri
On 9 Oct 2013, at 13:35, Steve Crocker wrote:
> Avri, > > Speaking as founding chair of SSAC, there wasn't even a requirement for operating procedures for SSAC much less a requirement they be vetted, reviewed or approved by the Board or any other group. As part of my role as chair of SSAC, I initiated the creation of the operating procedures as a pragmatic way of capturing the tidbits of we actually operated. It was specifically not intended to be a set of rules that bound the group to anything. Rather, it was intended as a compendium to help the group remember what it did before. That said, I noticed that once we wrote things down, people tended to interpret the words as binding. > > Taking your point more broadly, the bylaws given almost no guidance on the structure of SSAC. I didn't study the words associated with the other advisory committees as closely, but I think the situation is similar. The only specific operational requirement is for the Board to approve the membership on SSAC. In the beginning, there weren't any limitations on terms, there was any criteria regarding membership, there weren't any mechanisms for removing someone except, implicitly, to ask the Board to take such an action. I adopted a practice of presenting to the Board nominations and I did so with sufficient documentation to make it clear we had selected people with strong backgrounds. The Board routinely accepted all of our nominations, and when it came time to replace me as chair, the Board chose to ask SSAC to make the choice. > > SSAC now has three year terms for membership, renewable, and it has an internal process for selecting new members. > > Either within ATRT2 or through other community processes I can imagine attempting to provide guidance or impose structure on SSAC and/or other advisory committees. If so, I recommend approaching that question directly. Grabbing hold of the operating procedures may be helpful as part of such an effort, but I don't believe it's the right starting point or even the main issue. > > To press this point a bit further, SSAC has begun to complain that its advice hasn't been followed. As a matter of form, I think that's out of scope, but I also agree and am actively implementing that when they deliver advice it needs to be acknowledged and accounted for. We have wording in our current ATRT2 report that addresses this, which is fine with me. > > Steve > > On Oct 9, 2013, at 10:15 AM, Avri Doria <avri@ella.com> wrote: > >> On 9 Oct 2013, at 13:04, Steve Crocker wrote: >> >>>> page 12, There was no comment period or other mechanism for community input associated with the publication of the SSAC Operating Procedures >>> This wording inappropriately implies there should be a public comment period. The SSAC Operating Procedures is an internal document that captures the processes in effect. It is not a policy document. Publication is done for transparency and comments, if any, will likely be considered, but it was never intended nor would it be appropriate to suggest there is a need for community feedback or approval. >>> >> >> In general, I thought that all SO/AC Operating Procedures go through at least a vetting by the Board and that is preceded by a public comment. I certainly thought this was the case for GNSO Operating Principles. Not sure if this was the case for the ALAC change that just went through, but I thought it was. I don't understand why this would not be the case for SSAC as well. >> >> Or should we take this to mean that no SO/AC needs to go through public comment before changing it Operating procedures? >> >> Thanks >> >> avri >> >> _______________________________________________ >> atrt2 mailing list >> atrt2@icann.org >> https://mm.icann.org/mailman/listinfo/atrt2 > _______________________________________________ > atrt2 mailing list > atrt2@icann.org > https://mm.icann.org/mailman/listinfo/atrt2 > _______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
[Resending with omitted words inserted. Avri, Speaking as founding chair of SSAC, there wasn't even a requirement for operating procedures for SSAC much less a requirement they be vetted, reviewed or approved by the Board or any other group. As part of my role as chair of SSAC, I initiated the creation of the operating procedures as a pragmatic way of capturing the tidbits of how we actually operated. It was specifically not intended to be a set of rules that bound the group to anything. Rather, it was intended as a compendium to help the group remember what it did before. That said, I noticed that once we wrote things down, people tended to interpret the words as binding. Taking your point more broadly, the bylaws give almost no guidance on the structure of SSAC. I didn't study the words associated with the other advisory committees as closely, but I think the situation is similar. The only specific operational requirement is for the Board to approve the membership on SSAC. In the beginning, there weren't any limitations on terms, there wasn't any criteria regarding membership, and there weren't any mechanisms for removing someone except, implicitly, to ask the Board to take such an action. I adopted a practice of presenting to the Board nominations and I did so with sufficient documentation to make it clear we had selected people with strong backgrounds. The Board routinely accepted all of our nominations, and when it came time to replace me as chair, the Board chose to ask SSAC to make the choice. SSAC now has three year terms for membership, renewable, and it has an internal process for selecting new members. Either within ATRT2 or through other community processes I can imagine attempting to provide guidance or impose structure on SSAC and/or other advisory committees. If so, I recommend approaching that question directly. Grabbing hold of the operating procedures may be helpful as part of such an effort, but I don't believe it's the right starting point or even the main issue. To press this point a bit further, SSAC has begun to complain that its advice hasn't been followed. As a matter of form, I think that's out of scope, but I also agree and am actively implementing that when they deliver advice it needs to be acknowledged and accounted for. We have wording in our current ATRT2 report that addresses this, which is fine with me. Steve On Oct 9, 2013, at 10:15 AM, Avri Doria <avri@ella.com> wrote:
On 9 Oct 2013, at 13:04, Steve Crocker wrote:
page 12, There was no comment period or other mechanism for community input associated with the publication of the SSAC Operating Procedures
This wording inappropriately implies there should be a public comment period. The SSAC Operating Procedures is an internal document that captures the processes in effect. It is not a policy document. Publication is done for transparency and comments, if any, will likely be considered, but it was never intended nor would it be appropriate to suggest there is a need for community feedback or approval.
In general, I thought that all SO/AC Operating Procedures go through at least a vetting by the Board and that is preceded by a public comment. I certainly thought this was the case for GNSO Operating Principles. Not sure if this was the case for the ALAC change that just went through, but I thought it was. I don't understand why this would not be the case for SSAC as well.
Or should we take this to mean that no SO/AC needs to go through public comment before changing it Operating procedures?
Thanks
avri
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
Hi, On 9 Oct 2013, at 13:42, Steve Crocker wrote:
Either within ATRT2 or through other community processes I can imagine attempting to provide guidance or impose structure on SSAC and/or other advisory committees. If so, I recommend approaching that question directly. Grabbing hold of the operating procedures may be helpful as part of such an effort, but I don't believe it's the right starting point or even the main issue.
Just checking - does mean that they do not fall under the purview of the Structural Improvements Committee (SIC) that has had such an intensive influence on the charters and structure of the other SO/AC? avri
They fall under the structural review provisions in the bylaws, and, indeed there was a substantial review. The SIC oversees that process. Speaking again as past chair of SSAC, I was pleased that even though our review was in the middle of the pack in terms of when it was started, I believe we were the first to complete the review and implement the recommendations. All the information from the reviews is publicly available, of course. Steve On Oct 9, 2013, at 10:51 AM, Avri Doria <avri@ella.com> wrote:
Hi,
On 9 Oct 2013, at 13:42, Steve Crocker wrote:
Either within ATRT2 or through other community processes I can imagine attempting to provide guidance or impose structure on SSAC and/or other advisory committees. If so, I recommend approaching that question directly. Grabbing hold of the operating procedures may be helpful as part of such an effort, but I don't believe it's the right starting point or even the main issue.
Just checking - does mean that they do not fall under the purview of the Structural Improvements Committee (SIC) that has had such an intensive influence on the charters and structure of the other SO/AC?
avri
_______________________________________________ atrt2 mailing list atrt2@icann.org https://mm.icann.org/mailman/listinfo/atrt2
Hello all, I've read this thread with interest although I think it might have slipped on a tangent. Referring to an older message in the thread: On 09/10/2013 21:15, Avri Doria wrote:
In general, I thought that all SO/AC Operating Procedures go through at least a vetting by the Board and that is preceded by a public comment. I certainly thought this was the case for GNSO Operating Principles. Not sure if this was the case for the ALAC change that just went through, but I thought it was. I don't understand why this would not be the case for SSAC as well.
Or should we take this to mean that no SO/AC needs to go through public comment before changing it Operating procedures?
The ALAC has its function defined in the ICANN Bylaws. On the other hand, it has its own Rules of Procedures which vary in the level of detail, focussing primarily on elections, selections, appointments etc. and leaving it to the Chair of the ALAC to define the way policy discussion and other operational matters are undertaken. The ALAC, when it had its Review, went through the normal process with the SIC, with public comment period etc. As noted, the ALAC Review was presented to the Board Structural Improvements Committee (SIC), with all the bells & whistles that this entices. The Full Board needed to agree on two changes in ICANN bylaws - one to define the ALAC's Mission and the other to create Seat #15 on the Board. However, when reviewing its own internal Rules of Procedures, another process it carried out independently, it did not need a resolution from the Board nor a public comment. The one thing that the ALAC did, however, was to pass the whole document by ICANN Legal to make sure nothing in those Rules clash with ICANN Bylaws and other ICANN operating documents. And of course, the ALAC voted on the document. All of the ALAC's processes are published, including its process for structural improvements and its own internal improvements to its Rules of Procedures. I gather this is what Avri would like to see of the SSAC. I personally am in favour of lifting shrouds of Secrecy from all ICANN SOs/ACs, wherever possible. Possibly the most "Secret" of all ICANN Committees, the NomCom, has undertaken such opening of its processes, to the satisfaction of a lot of people in the Community. I haven't reviewed what information the SSAC is currently publishing about its processes so cannot judge if this is enough, but the litmus test on this is whether the Community understands how the SSAC operates or not. A comment by Steve has surprised me: "They don't actually talk about secret stuff, which I think is a limitation." Actually I know for a fact that they do have some confidential information that they discuss and sometimes work on. For example, newly found DNS weaknesses which require patching and action before they are announced. The Chair of the SSAC has shared such information with me in the past and I have shared it with his agreement, with select members of our community that work on technical security issues. For the record, I agree with Steve on being against the ATRT2 and/or other external Community processes imposing a structure on SSAC and/or other advisory committees. The members of SSAC know better what helps them most in their work. Whilst this may be documented today, perhaps should this be formalised by the SSAC itself -- and maybe I'm just stating the obvious and SSAC has already done that. Kind regards, Olivier -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html
On 10 Oct 2013, at 06:41, Olivier MJ Crepin-Leblond wrote:
However, when reviewing its own internal Rules of Procedures, another process it carried out independently, it did not need a resolution from the Board nor a public comment.
Ok, so it is only the GNSO that is subject to the regime of needing to have every little internal procedure change undergo full public comment. Thanks for correcting my understanding, I thought the ALAC ROP changes had undergone community comment and review. Apologies for my error. avri
At 10/10/2013 08:33 AM, Avri Doria wrote:
On 10 Oct 2013, at 06:41, Olivier MJ Crepin-Leblond wrote:
However, when reviewing its own internal Rules of Procedures, another process it carried out independently, it did not need a resolution from the Board nor a public comment.
Ok, so it is only the GNSO that is subject to the regime of needing to have every little internal procedure change undergo full public comment.
Thanks for correcting my understanding, I thought the ALAC ROP changes had undergone community comment and review.
Apologies for my error.
avri
The recent ALAC Rules of Procedure changes probably did not have to under go public comment of any sort and in fact, could probably (from a "legal" point of view) been determined solely within the ALAC. That is not what we chose to do. There was significant community involvement and comment (although not a formal ICANN Public Comment). That being said, there ARE aspects of the ALAC rules that do need Board approval. As an example, the rules for certifying and decertifying ALSs do require Board approval. Alan
At 10/10/2013 08:33 AM, Avri Doria wrote:
On 10 Oct 2013, at 06:41, Olivier MJ Crepin-Leblond wrote:
However, when reviewing its own internal Rules of Procedures, another process it carried out independently, it did not need a resolution from the Board nor a public comment.
Ok, so it is only the GNSO that is subject to the regime of needing to have every little internal procedure change undergo full public comment.
Thanks for correcting my understanding, I thought the ALAC ROP changes had undergone community comment and review.
Apologies for my error.
avri
One more point. I believe that it is all SOs that have to have overall operating procedures approved by the Board (or at least the Board has the right to object). I am less sure that all of the internal procedures need to be vetted to the same level or subject to full Public Comment, but I believe that the GNSO current procedures do call for such changes to be subject to such treatment (I asked when some small change recently had to wait for a PC before coming into effect). Alan
participants (8)
-
Alan Greenberg -
Avri Doria -
Brian Cute -
Demi Getschko -
Jørgen C Abild Andersen -
Larisa B. Gurnick -
Olivier MJ Crepin-Leblond -
Steve Crocker