3,197
edits
Changes
Jump to navigation
Jump to search
Line 225:
Line 225: − + − + + + + + + + + + + + +
→Public Comment on RWG Draft Report
===Public Comment on RWG Draft Report===
===Public Comment on RWG Draft Report===
The RWG presented its draft report at [[ICANN 36]] in Seoul.<ref>[https://archive.icann.org/en/meetings/seoul2009/node/7098.html ICANN 36 Archive - SSAC Review - Presentation of the Draft Report of the RWG], October 28, 2009</ref> [[Dennis Jennings]], chair of the RWG, took the audience through the recommendations presented above.<ref>[https://archive.icann.org/en/meetings/seoul2009/bitcache/Review%20of%20the%20SSAC%20-%20SSAC%20Review%20WG%20%C3%A2__%20Presentation%20of%20the%20Draft%20Report-vid=7453&disposition=attachment&op=download.pdf Presentation Slides - Draft Report of the RWG], October 28, 2009</ref>
The RWG presented its draft report at [[ICANN 36]] in Seoul.<ref>[https://archive.icann.org/en/meetings/seoul2009/node/7098.html ICANN 36 Archive - SSAC Review - Presentation of the Draft Report of the RWG], October 28, 2009</ref> [[Dennis Jennings]], chair of the RWG, and [[Marco Lorenzoni]], ICANN's Director of Organizational Reviews, took the audience through the recommendations presented above.<ref>[https://archive.icann.org/en/meetings/seoul2009/bitcache/Review%20of%20the%20SSAC%20-%20SSAC%20Review%20WG%20%C3%A2__%20Presentation%20of%20the%20Draft%20Report-vid=7453&disposition=attachment&op=download.pdf Presentation Slides - Draft Report of the RWG], October 28, 2009</ref> [[Steve Crocker]] provided apologies for other SSAC members who were attending a meeting on the root scaling study, which was occurring at the same time.<ref name="seoulaudio">[https://audio.icann.org/meetings/seoul2009/ssac-review-28oct09-en.mp3 Audio Recording - Presentation of the Draft Report of the SSAC1 RWG], October 28, 2009</ref> Throughout the presentation, Dr. Crocker acted as the voice of the SSAC self-assessment and its positions as presented to the RWG.
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]] 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>
====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.
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>
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>
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" />
[[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" />
Regional Internet Registries has not put resources into the IANA's security and stability, because we believed that
==References==
==References==