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.
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.
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.
