Changes

====Recommendations 5 and 6====

====Recommendations 5 and 6====

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]], then the president of [[ARIN]], noted 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> Curran made similar comments at the presentation in Seoul, and at the meeting <ref name="seoulaudio" /> he brought up the fact that the Regional Internet Registries rely on the SSAC as an advisory body for IANA functions. [[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 John 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), that SSAC does 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 needs to be examined to see whether or not that's an appropriate process. He noted that an operational reliance on SSAC was odd, and perhaps not a sensible way to continue.

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, but but I also didn't know that we 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>

<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 RIR's 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 Internet. 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 the DNS.<ref name="seoulaudio" />  

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 empowers the SSAC to act. Mohan responded that every change requires 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. Jennings also invited Curran to submit a written comment.

[[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" />

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" />

==References==

==References==