[Ssr2-coordination] Follow up from ICANN59

Emily Crane Pimentel emily.pimentel at icann.org
Fri Jul 7 14:07:28 UTC 2017


Denise, Eric and Emily,

 

I wanted to follow up on our meeting and on the request to adopt the title "Security Review" in public communications with a recap our discussion and suggest next steps. Coming out of our conversation, it was our sense that the underlying concern driving this idea is that people may not know what SSR2 means, and may not understand what’s being asked of them because of that, therefore volunteers/participation/interest may become limited to people who already understand the terminology. 

 

This is a valid concern, and something that we can help address. However, we do not believe that changing the name or shorthand for the review is going to fix that. We are also particularly cautious here, as the bylaws specifically name the review in Section 4.6(c), with SSR as the acronym. We don’t feel it is our role to change the name of the review, even in shorthand. That would be up to the global ICANN community to comment on and decide when reviewing the Bylaws.

 

That said, even developing a different shorthand such as “Security Review,” would not really address the problem you are trying to solve. Calling SSR2 “Security Review” marginalizes the stability and resiliency elements of the work, risking skewing participation and interest away from those interested in resiliency and stability, over security issues. We believe it would cause confusion, and even further, would require re-education of the target stakeholders, both new and community that have participated or followed the SSR review process up to this point. This would also increase the risk of accusations of scope change, or that the Review does not meet the bylaws requirements. 

 

Changing the shorthand midstream, from a logistical standpoint, would make it challenging for people to find accurate information and research the history of the review, should they chose to do so. We could undertake best efforts to mitigate this, but from a search and translation perspective it would be very challenging. And, spelling out the full Review name after “Security Review” each time is not correct grammatically, but also will not accomplish the goal of making things easier to understand. 

 

It is our suggestion that we instead commit to focusing more intentionally on the targeted audiences for each external facing piece of communication. For example, a request for public comment should use simple language and phrasing, explaining the importance of the review in ‘layman’s terms,’ and not rely upon acronyms and ICANN-ese. Looking at each piece of communication, identifying the audience who needs to understand it, and drafting the language to appeal to that audience will have a greater impact then changing the shorthand of the Review would. If we work together to add things like Executive summaries, and to complete documents in advance of deadlines so we can have translations available for posting, we can put out documents in a timely manner, supported by inclusion in ICANN social media channels and newsletters, that are in an accessible language, translated, and easier to understand for people outside of the ICANN Reviews world. 

 

Please let us know if you have any questions or would like to discuss further.

 

Thanks,

Emily

 

-- 

Emily Crane Pimentel

Internet Corporation for Assigned Names and Numbers 

emily.pimentel at icann.org

Office +1.202.570.7119

Mobile +1.703.581.8562

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ssr2-coordination/attachments/20170707/fe8dc8b9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4616 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ssr2-coordination/attachments/20170707/fe8dc8b9/smime.p7s>


More information about the ssr2-coordination mailing list