First SSAC Organizational Review: Difference between revisions
m removed Category:ICANN Reviews using HotCat |
|||
(4 intermediate revisions by one other user not shown) | |||
Line 49: | Line 49: | ||
After receipt of the IE's final report, the SSAC membership engaged in a self-assessment exercise, resulting in a report to the RWG in June 2009<ref name="wgdraft">[https://www.icann.org/en/system/files/files/ssac-review-wg-draft-report-18sep09-en.pdf SSAC1 - Draft Report of the RWG], September 18, 2009</ref> During [[ICANN 35]] in Sydney, the RWG discussed the final report from JAS as well as the SSAC self-assessment report, and began to formulate proposals for the implementation of improvements recommended in each report.<ref name="wgdraft" /> | After receipt of the IE's final report, the SSAC membership engaged in a self-assessment exercise, resulting in a report to the RWG in June 2009<ref name="wgdraft">[https://www.icann.org/en/system/files/files/ssac-review-wg-draft-report-18sep09-en.pdf SSAC1 - Draft Report of the RWG], September 18, 2009</ref> During [[ICANN 35]] in Sydney, the RWG discussed the final report from JAS as well as the SSAC self-assessment report, and began to formulate proposals for the implementation of improvements recommended in each report.<ref name="wgdraft" /> | ||
===Draft Report=== | ===RWG Draft Report=== | ||
In its draft report, the RWG collated the IE's recommendations, the SSAC's response, and the working group's consensus opinion on each recommendation from the IE's final report, as well as the additional recommendations from the SSAC Self-Assessment: | In its draft report, the RWG collated the IE's recommendations, the SSAC's response, and the working group's consensus opinion on each recommendation from the IE's final report, as well as the additional recommendations from the SSAC Self-Assessment: | ||
{| class="wikitable" | {| class="wikitable" | ||
Line 228: | Line 228: | ||
====Recommendations 5 and 6==== | ====Recommendations 5 and 6==== | ||
Recommendation 6 received a great deal of discussion, and Recommendation 5 was incorporated by reference halfway through the discussion, as they both addressed similar issues. [[John Curran]], president of [[ARIN]], objected to the language of Recommendation 6, as it excluded SSAC from information that it might need, rather than including SSAC in any situation where their advice might be important. During his conversation with Dennis Jennings, he emphasized that the Regional Internet Registries rely on the SSAC to serve as an advisory body for IANA functions.<ref name="seoulaudio" /> [[George Sadowsky]] intervened in that conversation and asked Steve Crocker if the RWG's conclusions on Recommendations 5 and 6 were likely to inhibit the work of the SSAC. Dr. Crocker responded with some history regarding the SSAC's past investigations and review actions, where in one case the SSAC was rebuffed in its attempt to review the internal operations of ICANN. Crocker agreed with Curran's opinion that 1) any material change to the operations of the IANA functions should signal a call for SSAC to review; and 2) on a regular basis (for example, annually), the SSAC should perform a ''pro forma'' review of operations and procedures. Dr. Crocker concluded, "the short answer, George, is yes, but I wanted to give the long answer first." Dennis Jennings stated that he was unaware, and did not think that the IE was aware, that the RIRs were reliant on SSAC. He suggested that perhaps the examination of those obligations was out of scope of the review, and moreover, that perhaps the IANA function needed to be examined to see whether or not that was an appropriate dependency. He noted that an operational reliance on SSAC was odd, and perhaps not a sensible way to continue. | |||
Crocker agreed and confirmed that he also did not know that the SSAC was "carrying that load." He went on: | Crocker agreed and confirmed that he also did not know that the SSAC was "carrying that load." He went on: | ||
<blockquote>Looking at this, I would have to say that, SSAC was invented, as we know, kind of in response to 9/11 without any specifics and clarity. And, then we began to do whatever we began to do. And I think what I'm certainly hearing as well for the first time, is the fact that other have been dependent upon us in a way that, had we not been there, other mechanisms might have evolved. And your point, Dennis, is maybe those mechanisms should be there because that would be the more formal and straightforward thing to do. And I don't necessarily disagree. I'm having quite mixed feelings of, well gosh, I didn't know that we'd been doing anything useful - that's good to know. And, uh, | <blockquote>Looking at this, I would have to say that, SSAC was invented, as we know, kind of in response to 9/11 without any specifics and clarity. And, then we began to do whatever we began to do. And I think what I'm certainly hearing as well for the first time, is the fact that other have been dependent upon us in a way that, had we not been there, other mechanisms might have evolved. And your point, Dennis, is maybe those mechanisms should be there because that would be the more formal and straightforward thing to do. And I don't necessarily disagree. I'm having quite mixed feelings of, well gosh, I didn't know that we'd been doing anything useful - that's good to know. And, uh, but I also didn't know that we were carrying this sort of responsibility, and now there's questions about what is that precisely and are we doing a good enough job and so forth.<ref name="seoulaudio" /></blockquote> | ||
Curran clarified: | Curran clarified: | ||
<blockquote>...the [[in-addr.arpa|in-addr]] domains, which are used for people to map backwards from numbers to names, actually turn out to be pretty important for a lot of applications, and while they occupy a very small amount of the DNS namespace, they potentially have larger impact, if not available, on a wider scope. And so, people don't think about the RIRs when they think about DNS, but we have a slice that is required to be operational which we don't spend a lot of attention worrying about because we recognize there's an expert group doing that. And so, this is not a question of reporting, we actually have a wonderful relationship with IANA, and we actually have formal reporting that has been set up between the NRO acting as the Address Supporting Organization, and the IANA. We just want to make sure that the IANA has access to resources of expertise when making significant changes, becuase a mistake made in that organization would have wide-reaching impact.<ref name="seoulaudio" /></blockquote> | <blockquote>...the [[in-addr.arpa|in-addr]] domains, which are used for people to map backwards from numbers to names, actually turn out to be pretty important for a lot of applications, and while they occupy a very small amount of the DNS namespace, they potentially have larger impact, if not available, on a wider scope. And so, people don't think about the RIRs when they think about DNS, but we have a slice that is required to be operational which we don't spend a lot of attention worrying about because we recognize there's an expert group doing that. And so, this is not a question of reporting, we actually have a wonderful relationship with IANA, and we actually have formal reporting that has been set up between the NRO acting as the Address Supporting Organization, and the IANA. We just want to make sure that the IANA has access to resources of expertise when making significant changes, becuase a mistake made in that organization would have wide-reaching impact.<ref name="seoulaudio" /></blockquote> | ||
Jeff Schmidt of JAS asked for clarification around what | Jeff Schmidt of JAS asked for clarification around what the RIRs' dependency was, and probed whether the dependency was in fact the proper operation of IANA, much as the rest of the Internet relies on a stable and functioning DNS. Curran demurred, pointing out that there were contractual obligations involved, and that ICANN's obligations to the RIRs were specific and narrowly focused on the stability and security of its part of that contract (i.e. the IANA functions).<ref name="seoulaudio" /> | ||
[[Ram Mohan]] commented that increasing bureaucracy around the SSAC's investigations powers or its right to inquire would only impair the SSAC's ability to predict and assess threats. George Sadowsky agreed that it seemed "stupid" to impede the SSAC's work. Dennis Jennings responded that his opinion of the RWG conclusion | [[Ram Mohan]] commented that increasing bureaucracy around the SSAC's investigations powers or its right to inquire would only impair the SSAC's ability to predict and assess threats. George Sadowsky agreed that it seemed "stupid" to impede the SSAC's work. Dennis Jennings responded that his opinion of the RWG conclusion empowered the SSAC to act. Mohan responded that every change would require the SSAC to "write a note" to the Board to get permission to examine the ramifications of the change. Jennings noted the comment and stated that he was reasonably certain that the implementation of the recommendation as written would result in an acceptable working relationship. Dr. Crocker stated that the SSAC has an opportunity to put the mechanism to the test. He also noted that informal requests had failed in the past - a layer of bureaucracy and publication of requests might generate some leverage and build a record.<ref name="seoulaudio" /> Jennings proposed that the RWG review the implementation in twelve months' time to see that it has had the desired effect. Mohan appreciated that commitment to review, so that the issue would not merely be deemed "resolved." Jennings also invited Curran to submit a written comment, and Curran agreed to do so.<ref name="seoulaudio" /> | ||
Noting that this was "the issue" of the review, Jeff Schmidt chimed in to state that "it is not the reviewer's position that these reviews of internal operations should not be done. Our issue was purely a governance issue." He noted that the IE report offered alternative processes, including having some security professionals on retainer to ICANN, to ensure that the security and stability of the massively important resource that was the Internet was preserved.<ref name="seoulaudio" /> | |||
====Written Comments==== | |||
The draft report was also published for written comments.<ref>[https://www.icann.org/resources/pages/ssac-review-2009-2009-10-05-en Public Comment Proceeding - SSAC1 Review Working Group Draft Report], October 5, 2009</ref> One comment was submitted via email. John Curran, as promised, submitted a comment stating that the SSAC's position on Recommendation 6 was correct, and that it was important for SSAC's charter to reflect its ability to engage with and advise on ICANN's internal operations and processes.<ref>[https://forum.icann.org/lists/ssac-review-2009/msg00000.html SSAC1 Listserv Archive - John Curran's comment on the Draft Report of RWG], October 28, 2009</ref> | |||
===RWG Final Report=== | |||
The Final Report of the RWG was submitted to the board in January 2010.<ref name="rwgfp">[https://www.icann.org/en/system/files/files/ssac-review-wg-final-report-29jan10-en.pdf SSAC1 - Review Working Group Final Report], January 29, 2010</ref> The final report is nearly identical to the draft, although the RWG's response and advice regarding Recommendation 5 (disclosure of confidential or proprietary information) changed in line with the discussion in Seoul.<ref name="rwgfp" /> the RWG suggested implementation of a more specific process, and a twelve-month trial period for that process: | |||
<blockquote>The WG agrees with the comments formulated by reviewers and based on sound governance considerations, but in the meantime agrees with SSAC and considers that there is no need to amend its Charter. | |||
It remarks that SSAC has a legitimate right to ask for access to confidential or proprietary information that is needed to fill its mandate, requests that need to be motivated by appropriate reasons. | |||
However, this does not imply the right for SSAC to force ICANN –or any other party – to disclose any requested confidential or proprietary information. In case of its disclosure, this information has to be treated under the terms set/to be set by the owners of the information; this could imply the signing of time and project‐specific confidentiality agreements or other measures considered appropriate by the information owners | |||
In the case of requests to ICANN the WG suggests that the CEO, and if necessary the Board, should decide on the access to confidential or proprietary information, considering the reasons for the request, and the possibility to set and enforce specific terms of access. Any recurrence of this process should be properly documented. | |||
This process should not however result in unnecessary delays to the work of SSAC; the WG advises therefore the Board to assess the effectiveness of this procedure after one year from its adoption.<ref name="rwgfp" /></blockquote> | |||
Perhaps reflecting Dennis Jennings' belief that the RWG's conclusion regarding Recommendation 6 was strong enough, particularly when bolstered by the process proposed in the revised response to Recommendation 5, the final report made no changes to its response to Recommendation 6.<ref name="rwgfp" /> | |||
The RWG also added a note to Recommendation 30, noting that an "informal" process of conflicts disclosure should still involve documenting situations when conflicts of interests arise, and maintaining records of those incidents in a transparent manner.<ref name="rwgfp" /> | |||
==Board Action and Implementation== | |||
The board acknowledged receipt of the RWG's final report in March 2010, and instructed the SIC to develop and propose an implementation plan for the review recommendations.<ref>[https://www.icann.org/resources/board-material/resolutions-2010-03-12-en#1.6 Board Resolutions 2010.03.12.09-12], March 12, 2010</ref> The implementation plan was developed by the SIC and SSAC support staff,<ref>[https://www.icann.org/resources/board-material/resolutions-2010-06-25-en#1.4 Resolution (2010.06.25.05) of the Board], June 25, 2010</ref> and subsequent implementation efforts continued throughout 2010 and into 2011. On March 18, 2011, the SSAC presented its final implementation report, marking all implementation tasks as complete.<ref>[https://www.icann.org/en/system/files/files/improvements-implementation-plan-18mar11-en.pdf SSAC1 - Improvements Implementation Plan (Final)], March 18, 2011</ref> This marked the end of the SSAC1 review.<ref name="dashboard" /> | |||
==References== | ==References== | ||
{{reflist}} | {{reflist}} | ||
[[Category:Organizational Reviews]] | [[Category:Organizational Reviews]] |