FINAL VERSION SUBMITTED (IF RATIFIED)
The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote.
FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC
The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.
03 December 2018 - Seun Ojedeji
The ALAC appreciates the opportunity to provide comment on the Draft Final Report of The Second Security and Stability Advisory Committee (SSAC2) Review (SSAC2). The ALAC has considered the report and would like to make the following remarks:
Recommendation 1:
We very much support the recommendation that the SSAC has a clear continuing purpose within ICANN, and that its existence as an Advisory Committee should therefore continue. As the reviewer notes, and we consider this also applicable to the At-Large community, "Interviewees who self-identified as non-technical members of the ICANN community widely agreed that they rely on and expect the SSAC to proactively help the community, including those without technical backgrounds, on technical issues related to the security, stability, and reliability of processes and decisions regarding the DNS and root zone."
Recommendation 2:
The ALAC supports the intent behind the recommendation to "ensure that each advisory or report provided to the ICANN Board includes a high-level summary that outlines the topic or issue in easily understandable terms and lists the key findings with uniquely numbered recommendations." However, the ALAC would like to note that while it appreciates the SSAC prepares advice in a format to better communicate with the Board, the SSAC should also simultaneously attempt to write advice in such a way that the rest of the ICANN community more easily understands them, too. Again, this applies especially to the At-Large community which has many members who lack a sufficient level of technical background.
Recommendations 3 & 4:
In general terms, the ALAC supports these. In line with recommendation 4, the ALAC thinks it is important that the "Board Action Request Register adequately captures the information required to understand the status of advice from when it is given through its implementation." The ARR should of course allow the ICANN community to quickly and easily understand the status of the advice made to the ICANN Board. Therefore, the final process for updating the ARR should indeed be clear, and each item under implementation should have a known point of contact who can speak to its current status when asked.
Recommendation 5:
It is important that advice from the SSAC is addressed by the Board and that (non) progress is clear. The Board Liaison seems the one who can follow up on this within the Board on behalf of the SSAC. The ALAC agrees with the reviewer’s remark that "ultimately, the ARR should be a tool that the SSAC can use to understand what happens to the advice and recommendations that the SSAC has given. While it is not the SSAC’s role to implement advice, the SSAC should be able to know that its advice is being duly considered and, when appropriate, implemented."
Recommendation 8:
As indicated by the reviewer, the SSAC has strong technical expertise and almost all interviewees indicated that the SSAC is generally well-prepared for SSR threats that may occur in the future. Less technical interviewees however indicated that they do not have the background to know if the SSAC is appropriately evaluating the security landscape to pick topics of research focus, and these interviewees therefore stated they rely on the SSAC to do so. This goes for the At-Large community, too. This reliance could indicate that there is need to develop more formal procedures geared towards identifying emerging threats as an input to setting research priorities for the SSAC, compared to the existing way that topics of interest are chosen. Therefore, the ALAC agrees with the intent of recommendation 8, but we do not know whether the "lightweight process" described is specific enough for the SSAC to take into consideration.
Recommendation 10:
The ALAC agrees with the idea, if a "lightweight" topic selection or something comparable is implemented, that the SSAC explicitly communicates what the reason for the selection has been and why the topic is of importance for ICANN.
Recommendation 12:
The ALAC likes the idea of the SSAC offering internships to graduate students who can assist with specific topics that the SSAC is working on or intends to work on.
Recommendation 14:
The ALAC agrees with the statement, part of the recommendation, that "the SSAC needs to be aware of policymaking that is ongoing within ICANN." The ALAC thinks the SSAC already does so, but the SSAC having liaisons to each Support Organization/Advisory Committee (SO/AC) might make this more effective and embedded in SSAC’s procedures.
Currently the ALAC has a liaison with the SSAC, and we are happy with this. We would be more than open for the SSAC to have a liaison with the ALAC. However, we understand that this might be demanding on the SSAC given limited resources. We would be happy to discuss this with the SSAC, but ultimately it would be up to them.
Recommendation 16:
The ALAC supports the recommendation to have the SSAC explicitly consider who might be affected by documents the SSAC intends to publish and whether these parties should be consulted for feedback or at least be notified in advance. The ALAC would encourage the SSAC to proactively discuss with other stakeholders how they might be affected, and whenever possible to engage them throughout the work being undertaken in stead of sharing the information ex-post when it is published as an advice.
Recommendation 17:
The ALAC supports any recommendation that can help improve how the SSAC provides updates to the ICANN community and the leadership of SOs and ACs before an ICANN meeting. In line with the recommendation, this could be done via email, however we suggest that such communication should also be disseminated copied via the SO/AC liaisons to the SSAC.
Recommendations 21, 22, 24 and 25:
The ALAC supports these recommended actions to improve and ensure the stable influx of new and high quality SSAC members. At the end of the day, it is about what these members can bring for the SSAC and the ICANN community in terms of the expertise and advice they provide, and as proposed by the reviewer ALAC encourages diversity within SSAC membership as much as possible.
DRAFT SUBMITTED FOR DISCUSSION
The first draft submitted will be placed here before the call for comments begins. The Draft should be preceded by the name of the person submitting the draft and the date/time. If, during the discussion, the draft is revised, the older version(S) should be left in place and the new version along with a header line identifying the drafter and date/time should be placed above the older version(s), separated by a Horizontal Rule (available + Insert More Content control).
02 December 2018 - Bastiaan Goslings, incorporating comments from Seun Ojedeji, Hadia Elminiaiwi, Carlton Samuels; EE edits in red.
The ALAC appreciates the opportunity to provide comment on the Draft Final Report of The Second Security and Stability Advisory Committee (SSAC2) Review (SSAC2). The ALAC has considered the report and would like to make the following remarks:
Recommendation 1:
We very much support the recommendation that the SSAC has a clear continuing purpose within ICANN, and that its existence as an Advisory Committee should therefore continue. As the reviewer notes, and we consider this also applicable to the At-Large community, "Interviewees who self-identified as non-technical members of the ICANN community widely agreed that they rely on and expect the SSAC to proactively help the community, including those without technical backgrounds, on technical issues related to the security, stability, and reliability of processes and decisions regarding the DNS and root zone."
Recommendation 2:
The ALAC supports the intent behind the recommendation to "ensure that each advisory or report provided to the ICANN Board includes a high-level summary that outlines the topic or issue in easily understandable terms and lists the key findings with uniquely numbered recommendations." However, the ALAC would like to note that while it appreciates the SSAC prepares advice in a format to better communicates with the Board, the SSAC should also simultaneously attempt to write advices in such a way that the rest of the ICANN community more easily understands them, too. Again, this applies especially to the At-Large community which has many members who lack a sufficient level of technical background.
Recommendations 3 & 4:
In general terms, the ALAC supports these. In line with recommendation 4, the ALAC thinks it is important that the "Board Action Request Register adequately captures the information required to understand the status of advice from when it is given through its implementation." The ARR should of course allow the ICANN community to quickly and easily understand the status of the advice made to the ICANN Board. Therefore, the final process for updating the ARR should indeed be clear, and each item under implementation should have a known point of contact who can speak to its current status when asked.
Recommendation 5:
It is important that advice from the SSAC is addressed by the Board and that (non) progress is clear. The Board Liaison seems the one who can follow up on this within the Board on behalf of the SSAC. The ALAC agrees with the reviewer’s remark that "ultimately, the ARR should be a tool that the SSAC can use to understand what happens to the advice and recommendations that the SSAC has given. While it is not the SSAC’s role to implement advice, the SSAC should be able to know that its advice is being duly considered and, when appropriate, implemented."
Recommendation 8:
As indicated by the reviewer, the SSAC has strong technical expertise and almost all interviewees indicated that the SSAC is generally well-prepared for SSR threats that may occur in the future. Less technical interviewees however indicated that they do not have the background to know if the SSAC is appropriately evaluating the security landscape to pick topics of research focus, and these interviewees therefore stated they rely on the SSAC to do so. This goes for the At-Large community, too. This reliance could indicate that there is need to develop more formal procedures geared towards identifying emerging threats as an input to setting research priorities for the SSAC, compared to the existing way that topics of interest are chosen. Therefore, the ALAC agrees with the intent of recommendation 8, but we do not know whether the "lightweight process" described is specific enough for the SSAC to take into consideration.
Recommendation 10:
The ALAC agrees with the idea, if a "lightweight" topic selection or something comparable is implemented, that the SSAC explicitly communicates what the reason for the selection has been and why the topic is of importance for ICANN.
Recommendation 12:
The ALAC likes the idea of the SSAC offering internships to graduate students who can assist with specific topics that the SSAC is working on or intends to work on.
Recommendation 14:
The ALAC agrees with the statement, part of the recommendation, that "the SSAC needs to be aware of policymaking that is ongoing within ICANN." The ALAC thinks the SSAC already does so, but the SSAC having liaisons to each Support Organization/Advisory Committee (SO/AC) might make this more effective and embedded in SSAC’s procedures.
Currently the ALAC has a liaison with the SSAC, and we are happy with this. We would be more than open for the SSAC to have a liaison with the ALAC. However, we understand that this might be demanding on the SSAC given limited resources. We would be happy to discuss this with the SSAC, but ultimately it would be up to them.
Recommendation 16:
The ALAC supports the recommendation and encourages the SSAC to discuss potential parties that might be affected by the issue under study, and whenever possible engage relevant parties throughout the work party process and not only upon the approval of the final recommendation.
Recommendation 17:
The ALAC supports any recommendation that can help improve how the SSAC provides updates to the ICANN community and the leadership of SOs and ACs before an ICANN meeting. In line with the recommendation, this could be done via email, however we suggest that such communication should also be disseminated copied via the SO/AC liaisons to the SSAC.
Recommendations 21, 22, 24 and 25:
The ALAC supports these recommended actions to improve and ensure the stable influx of new and high quality SSAC members. At the end of the day, it is about what these members can bring for the SSAC and the ICANN community in terms of the expertise and advice they provide, and as proposed by the reviewer ALAC encourages diversity within SSAC membership as much as possible.
27 November 2018 - Seun Ojedeji
We appreciate the opportunity to provide comment on the Security and Stability Advisory Committee (SSAC) review. The ALAC has considered the report and would like to make a few remarks:
Recommendation 1. We support the recommendation for SSAC to continue to exist as an advisory body within ICANN and we indeed support their effort in engaging the other part of the ICANN community.
Recommendation 2: The ALAC supports the intent behind this recommendation, however the ALAC will appreciate that while SSAC prepare its advice in a format that better communicate to the Board, she should also write them in such a way that will enable other part of the ICANN community easily understand the advice especially to the At-Large community that has members without certain level of technical background.
Recommendations 3&4: To the extent that we support this, we do hope that the process will not become a vetting exercise where critical substance of the advice to the Board is lost; We hope that the Independence of the SSAC at giving undiluted advice will remain upheld
Recommendation 14: While ALAC currently have a liaison to SSAC, we are also open to a SSAC liaison to ALAC. However we understand that this may be somewhat demanding on SSAC given the relatively few number of SSAC members
Recommendation 17: ALAC supports the recommendation to improve how SSAC provide updates to the ICANN community through their various leadership. We will suggest that such communication also be copied to applicable SO/AC liaisons to SSAC.
Recommendation 21&22&24&25: ALAC supports the recommended actions to improve the membership based of SSAC and the quality of its members. ALAC would like to encourage diversity within SSAC membership as much as possible.
12 Comments
Seun Ojedeji
Can staff kindly include the reference to previous comments that were made by ALAC on this? This request is not only related to this but will be good to do so for other PC with revisions.
I volunteer to hold the pen on this
Evin Erdogdu
Dear Seun, thank you for this comment. You may see all "Security/Stability" related ALAC Statements in the At-Large website Policy Summary by checking the topic box. Here is a recent ALAC statement regarding ICANN's remit in security, for your reference:
30 August 2012 ALAC Reply to Comments on the Draft Statements of ICANN's Role and Remit in Security, Stability, and Resiliency of the Internet's Unique Identifier System
Seun Ojedeji
Seun Ojedeji
Hello,
Here is a first draft attempt on the response to the PC:
"We appreciate the opportunity to provide comment on the Security and Stability Advisory Committee (SSAC) review. The ALAC has considered the report and would like to make a few remarks:
Recommendation 1. We support the recommendation for SSAC to continue to exist as an advisory body within ICANN and we indeed support their effort in engaging the other part of the ICANN community.
Recommendation 2: The ALAC supports the intent behind this recommendation, however the ALAC will appreciate that while SSAC prepare its advice in a format that better communicate to the Board, she should also write them in such a way that will enable other part of the ICANN community easily understand the advice especially to the At-Large community that has members without certain level of technical background.
Recommendation 3&4: To the extent that we support this, we do hope that the process will not become a vetting exercise where critical substance of the advice to the Board is lost; We hope that the Independence of the SSAC at giving undiluted advice will remain upheld
Recommendation 14: While ALAC currently have a liaison to SSAC, we are also open to a SSAC liaison to ALAC. However we understand that this may be somewhat demanding on SSAC given the relatively few number of SSAC members
Recommendation 17: ALAC supports the recommendation to improve how SSAC provide updates to the ICANN community through their various leadership. We will suggest that such communication also be copied to applicable SO/AC liaisons to SSAC
Recommendation 21&22&24&25: ALAC supports the recommended actions to improve the membership based of SSAC and the quality of its members. ALAC would like to encourage diversity within SSAC membership as much as possible."
Carlton Samuels
I would recommend that the ALAC endorse Rec #12 - Internship. I know this would be of interest to would-be tech interests and should be encouraged.. Plus it gives them a way to early spot and develop a talent pool
I would also be wary of recommending the SSAC respond to the knock of every drum. I can tell you I pay attention to the SSAC's publications and find them more authoritative if only because I know it is reflective and good cogitation time was expended in gestation. If it is one thing I think undermine the ALAC's influence in ICANN is this need we think is entrusted on us to respond to every fickle thing.
Carlton
Seun Ojedeji
Bastiaan Goslings
I took Seun's intial draft and edited it and added points:
We appreciate the opportunity to provide comment on the Security and Stability Advisory Committee (SSAC2) review. The ALAC has considered the report and would like to make the following remarks:
Recommendation 1:
We very much support the recommendation that the SSAC has a clear continuing purpose within ICANN, and that its existence as an Advisory Body should therefore continue. As the reviewer notes, and we consider this also applicable to the At-Large community, ‘Interviewees who self-identified as non-technical members of the ICANN community widely agreed that they rely on and expect the SSAC to proactively help the community, including those without technical backgrounds, on technical issues related to the security, stability, and reliability of processes and decisions regarding the DNS and root zone’.
Recommendation 2:
The ALAC supports the intent behind the recommendation to ‘ensure that each advisory or report provided to the ICANN Board includes a high-level summary that outlines the topic or issue in easily understandable terms and lists the key findings with uniquely numbered recommendations.’ However, the ALAC would like to note that while it appreciates the SSAC prepares advice in a format to better communicates to the Board, the SSAC should also simultaneously attempt to write advices in such a way that the rest of the ICANN community more easily understands them too. Again, this applies especially to the At-Large community which has many members who lack a sufficient level of technical background.
Recommendations 3&4:
In general terms the ALAC supports these. In line with recommendation 4 the ALAC thinks it is important that the ‘Board Action Request Register adequately captures the information required to understand the status of advice from when it is given through its implementation.’ The ARR should of course allow the ICANN community to quickly and easily understand the status of the advice made to the ICANN Board. And therefore the final process for updating the ARR should indeed be clear, and each item under implementation should have a known point of contact who can speak to its current status when asked.
Recommendation 5:
It is important that advice from the SSAC is addressed by the Board and that (non) progress is clear. The Board Liason seems the one who can follow up on this within the Board on behalf of the SSAC. The ALAC agrees with the reviewer’s remark that ‘ultimately, the ARR should be a tool that the SSAC can use to understand what happens to the advice and recommendations that the SSAC has given. While it is not the SSAC’s role to implement advice, the SSAC should be able to know that its advice is being duly considered and, when appropriate, implemented.’
Recommendation 8:
As indicated by the reviewer, the SSAC has strong technical expertise and almost all interviewees indicated that the SSAC is generally well-prepared for SSR threats that may occur in the future. Less technical interviewees however indicated that they do not have the background to know if the SSAC is appropriately evaluating the security landscape to pick topics of research focus, and these interviewees therefore stated they rely on the SSAC to do so. This goes for the At-Large community too. This reliance could indicate that there is need to develop more formal procedures geared towards identifying emerging threats as an input to setting research priorities for the SSAC, compared to the existing way that topics of interest are chosen. Therefor the ALAC agrees with the intent of recommendation 8, but we do not know whether the ‘lightweight process’ described is specific enough for the SSAC to take into consideration.
Recommendation 10:
The ALAC agrees with the idea, if a ‘lightweight’ topic selection or something comparable is implemented, that the SSAC explicitly communicates what the reason for the selection has been and why the topic is of importance for ICANN.
Recommendation 12:
The ALAC likes the idea of the SSAC offering internships to graduate students who can assist with specific topics that the SSAC is working on or intends to work on.
Recommendation 14:
The ALAC agrees with the statement, part of the recommendation, that ‘the SSAC needs to be aware of policymaking that is ongoing within ICANN.’ The ALAC thinks the SSAC already does so, but the SSAC having liasons to each SO/AC might make this more effective and embedded in SSAC’s procedures.
Currently the ALAC has a liaison with the SSAC, and we are happy with this. We would be more than open for the SSAC to have a liaison with the ALAC. However, we understand that this might be demanding on the SSAC given limited resources. We would be happy to discuss this with the SSAC, but ultimately it would be up to them.
Recommendation 17:
The ALAC supports any recommendation that can help improve how the SSAC provides updates to the ICANN community and the leadership of SO’s and AC’s before an ICANN meeting. In line with the recommendation this could be done via email, however we suggest that such communication should also be disseminated copied via the SO/AC liaisons to the SSAC.
Recommendations 21, 22, 24 and 25:
The ALAC supports these recommended actions to improve and ensure the stable influx of new and high quality SSAC members. At the end of the day it is about what these members can bring for the SSAC and the ICANN community in terms of the expertise and advice they provide, but the as proposed by the reviewer ALAC encourages diversity within SSAC membership as much as possible.
Hadia Elminiawi
Thank you Seun and Bastian, I support your drafts and would like to add a comment with regard to recommendation number 16
Recommendation 16:
The ALAC Supports the recommendation and encourages the SSAC to discuss potential parties that might be affected by the issue under study and whenever possible engage relevant parties throughout the work party process and not only upon the approval of the final recommendation.
Seun Ojedeji
The edits in red are fine, kindly commit Evin
Evin Erdogdu
Thank you for confirming, Seun. They will be incorporated into the final draft.
Bastiaan Goslings
Thanks Evin - I too agree with the final edits.
And if I am still on time:
I agree with the added comment on recommendation 16, but reading the text I had to go back to the report because I did not know what the recommendation actually consisted of.
Maybe as an alternative:
Recommendation 16:
The ALAC supports the recommendation to have the SSAC explicitly consider who might be affected by documents the SSAC intends to publish and whether these parties should be consulted for feedback or at least be notified in advance. The ALAC would encourage the SSAC to proactively discuss with other stakeholders how they might be affected, and whenever possible to engage them throughout the work being undertaken in stead of sharing the information ex post when it is published as an advice.
Evin Erdogdu
Thank you Bastiaan - I have added your suggested comment into the final text. CC: Seun Ojedeji Hadia Elminiawi