<div dir="ltr"><div><div><div>Hi all,<br><br>I undertook on our last call to pull together some initial thoughts to guide us on our session with the ATRT2 next week in BA. <br><br>I hadn't quite anticipated how long the whole report is...<br>
<br></div>Now focusing on the GNSO PDP side of it, but in the meantime here are some possible pointers on the SSR RT draft report - pasted below.<br><br></div>You'll find the reports proper here: <a href="http://www.icann.org/en/news/public-comment/atrt2-recommendations-21oct13-en.htm">http://www.icann.org/en/news/public-comment/atrt2-recommendations-21oct13-en.htm</a><br>
<br></div>All the best, Maria<br><br>
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"ＭＳ 明朝";
mso-font-charset:78;
mso-generic-font-family:auto;
mso-font-pitch:variable;
mso-font-signature:-536870145 1791491579 18 0 131231 0;}
@font-face
{font-family:"ＭＳ 明朝";
mso-font-charset:78;
mso-generic-font-family:auto;
mso-font-pitch:variable;
mso-font-signature:-536870145 1791491579 18 0 131231 0;}
@font-face
{font-family:Cambria;
panose-1:2 4 5 3 5 4 6 3 2 4;
mso-font-charset:0;
mso-generic-font-family:auto;
mso-font-pitch:variable;
mso-font-signature:-536870145 1073743103 0 0 415 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:"";
margin:0cm;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:Cambria;
mso-ascii-font-family:Cambria;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"ＭＳ 明朝";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Cambria;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
font-family:Cambria;
mso-ascii-font-family:Cambria;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"ＭＳ 明朝";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Cambria;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;
mso-header-margin:36.0pt;
mso-footer-margin:36.0pt;
mso-paper-source:0;}
div.WordSection1
{page:WordSection1;}
-->
</style>
<p class="MsoNormal"><span style> </span>ATRT2 Report(s)</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Appendix C – SSR
Review Implementation</b></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Recommendations 1 - 9 largely on definition of terms, role,
responsibilities, priorities of SSR in the ICANN context, possibilities for
external certification of functions including IANA, SSAC key management and IT,
and also about adequately resourcing the SSR function within the organisation.
They all sound supportable and worthwhile, especially on external and
community-wide coordination and continuing the now established annual reporting
requirements for the function.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">One question, though, why was budget information on support
for SSAC and RSSAC apparently redacted? (Maybe it’s available elsewhere in the
annual budget – I just haven’t checked and didn’t immediately see why it wasn’t
here. Shouldn't that info be available, and if not, why not?)</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 10</b></p>
<p class="MsoNormal">“ICANN should continue its efforts to step up contract
compliance enforcement and provide adequate resources for this function. ICANN
should also develop and implement a more structured process for monitoring
compliance issues and investigations.”</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Reporting and recommendations on Rec. 10 on compliance seems
weak, possibly because the recommendation is somewhat vague(it just says to
‘increase enforcement efforts’, so any increase, however small, is
implementation). ATRT2 states several times that the level of compliance or its
allocated resources are adequate are <i style>subjective
evaluations</i>. <span style> </span>It also notes community
concerns that resources may not be sufficient for future compliance demands of
new RAA and RA.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Essentially ATRT2 says improvements have been made but
doesn’t attempt to say if they are enough, as that would be subjective. Given
contract compliance and enforcement are at least partly empirically measurable,
and we have metrics to show and track progress, is the ATRT2 response itself
adequate? If we have no current way of measuring whether compliance work is
sufficient and sufficiently resourced, shouldn’t we look at developing some?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 11</b></p>
<p class="MsoNormal">“ICANN should finalize and implement measures f success for
new gTLDs and IDN Fast Track that expressly relate to its SSR-related program
objectives, including measurements for the effectiveness of mechanisms to
mitigate domain name abuse.”</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">ATRT2 reports that nothing’s yet been done on this and it’s
a community-staff collaboration. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Is this priority being fed into any existing policy or
implementation processes, and, if not, does or should the GNSO have a role in
moving it forward?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 12</b></p>
<p class="MsoNormal">“ICANN should work with the community to identify
SSR-related best practices for the community and encouragement for putting
those best practices into contracts, agreements, MOUs and other mechanisms.”</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">This was supposed to trigger a staff community dialogue on
which SSR-related best practices might be relevant and how they should be
incorporated. Registry input questioned whether contracts were the best way to
do this. No dialogue explicit to the recommendation has happened, though the
ATRT2 report includes law enforcement input to the RAA as part of it. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">As the RAA and RA negotiations are not subject to full
community dialogue, should the ATRT2 seem to be accepting that even some indirect
progress has been made on this item? Is there going to be any process to
identify best practices, analyse whether they should be linked to contracts and
subjected to full community dialogue? If not, then perhaps the ATRT2 report
should red flag this one as not begun, not implemented and not having any way
forward currently foreseen.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 13</b></p>
<p class="MsoNormal">“ICANN should encourage all SOs to develop and publish
SSR-related best practices for their members.”</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">The ccNSO is already doing this and the report on actions
taken says staff is ‘reaching out’ to the GNSO. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">While this all sounds good and worthwhile, how relevant is
the recommendation to the very heterogeneous GNSO? (I may well be missing the connection
here and would be happy to be corrected.) It may be that this recommendation
isn’t ever going to be implemented fully. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Which raises a larger question; is there a means for ATRT
reviews to suggest previous recommendations for retirement, in a way that
includes public consultation? (I don’t imply that there isn’t such a mechanism
– just asking the question.)</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 14</b></p>
<p class="MsoNormal">Ensure SSR-related outreach evolves to stay relevant and
useful, with feedback from the community. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">From the report, this seems to be happening and being done
increasingly and well, though I’m not sure what if any the transparent feedback
mechanisms are (or if they are further needed – just raising an open question).</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 15</b></p>
<p class="MsoNormal">“ICANN should act as facilitator in the responsible disclosure
and dissemination of DNS security threats and mitigation techniques.”</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Implementation seems to be going fine, though some concerns
expressed about escalating reports. Coordinated Vulnerability Disclosure
guidelines published to help. Unclear whether ICANN really is a needed locus
for this. <span style> </span></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span style> </span><b style>Rec. 16</b></p>
<p class="MsoNormal">Get more community and ecosystem input into SSR Framework
development process. No process for ecosystem input. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Very few public comments to SSR Framework – despite a lot of
effort from staff to elicit it that I’ve personally noticed. Better explaining
ICANN’s SSR role to outside organisations has helped encourage feedback from
them. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Should ICANN have a less informal process for getting input
from other organisations?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 17</b></p>
<p class="MsoNormal">More structured internal process to show how SSR work done
relates to priorities in SSR framework, with metrics and milestones.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Implementation underway and slotting into Strategic Plan and
project management organisation-wide. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">This is something of a no-brainer for us to encourage, I
think, and look forward to next ATRT reviewing and finding it pretty much
embedded.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 18</b></p>
<p class="MsoNormal">Do an annual SSR operational review in the annual SSR
Framework.</p>
<p class="MsoNormal"><span style> </span></p>
<p class="MsoNormal">Done & embedded. Great!</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 19</b></p>
<p class="MsoNormal">Establish something like a dashboard to let community track
implementation of SSR framework. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">This will be done through the ‘At Task’ management system.
Not yet implemented, but something we would probably welcome. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span style> </span><b style>Rec. 20</b></p>
<p class="MsoNormal">More transparent info on organisation and budget of SSR
work. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">ccNSO and others said to previous ATRT there needs to be
more info on this. It’s apparently coming in the FY14 budget and plan and
related ‘At Task’ tracking. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Registries strongly support more transparency on this. I
expect most of GNSO probably does, too, and we might say so when we meet ATRT2.
</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 21</b></p>
<p class="MsoNormal">More structured internal process to show how organisation
and budget decisions related to SSR Framework, ‘including the underlying
cost-benefit analysis’. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Happening through FY14 op plan and budget, and ‘At Task’ but
not yet done. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">It’s too early for community feedback on ‘how’ it’s being
done, but we may want to support it being done, and soon. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 22</b></p>
<p class="MsoNormal">Publish, monitor and update documentation on organisational
and budget resources to manage SSR issues re. New gTLDs. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Implementation underway as above, too early to see if it’s
effective. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Again, perhaps a simple recommendation that this is
important and should get done sooner rather than later, especially if we think
that increased resources may be needed wrt new gTLDs. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 23</b></p>
<p class="MsoNormal">Provide enough resources for SSR related working groups and
advisory committees, and ensure they make decisions “in an objective manner
that is free from external or internal pressure.”</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Security related work is done across all of ICANN SOs and
ACs as well as SSAC and RSSAC. Previous ATRT report said RSSAC probably had
enough support but SSAC was under resource pressure. Work is being done to
inventories SSR work across SOs and ACs. Results still TBA. RSSAC and SSAC
chairs say requests for funds not turned down but staff support a little thin. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Budget for SSAC and RSSAC redacted – not sure why. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">“WRT to ensuring decisions reached objectively and are free
from pressure, this component of the recommendation has yet to be implemented.”</p>
<p class="MsoNormal">This seems a little dismissive – is / can analysis be done
to ensure this? If not, why not and should it be attempted?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 24</b></p>
<p class="MsoNormal">Define role of Chief Security Officer Team.</p>
<p class="MsoNormal">Implemented in FY13 SSR Framework though with infographics
rather than text.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">ATRT2 says its happy with the security team taking a
‘somewhat dynamic’ approach so they can respond to emerging issues. Does this
sound fair? (It does to me – but others may differ.)</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 25</b></p>
<p class="MsoNormal">Put in place mechanisms to identify near and longer term
risks and strategic factors, informed by research, business partnerships SOs
and others. Publish this, recognising some may be too sensitive.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">ICANN hired Westlake Governance to develop a DNS Risk
Managmenet Framework. Draft was presented in Beijing and upfor comment in
Durban – staff now working on implementing along with work of DSSA Working
Group. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Public comments supported a stronger risk management
function at ICANN. In public comments on Westlake report there was “significant
disappointment that the work of the DSSA WG wasn’t incorporated more fully into
the DNS Risks Framework” and that “the choice of framework architecture
(ISO31000 over NIST 800-30) may have been sub-optimal.” And that DNS Risks
Framework too limited in terms of ICANN’s overarching SSR-related
responsibilities. Staff says the DSSA WG work will be incorporated. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">ATRT concludes that efforts are underway to meet overall
recommendation 25 but that the Westlake controversy hampered it so it’s not yet
able to assess the effectiveness of implementation.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">This seems a shame, but I know absolutely nothing about it!
If others think the GNSO has anything useful to say on this one that the SSR RT
hasn’t covered, then please have at it. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 26</b></p>
<p class="MsoNormal">Quickly finish the Risk Management Framework with lots of
participation and transparency. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">There have been sessions on this in Costa Rica, Prague,
Toronto and Beijing and public comments on the Westlake framework. SSR RT says
work to date has been ‘open and inclusive, and participation has been
welcomed’.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">As in 25, some unhappiness re. Westlake v the DSSA WG. SSR
RT says it looks like ICANN has prioritised this as recommended, but has been
hampered by a lack of clarity on respective roles of Westlake and DSSA WG. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Is standard of participation sufficiently high?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 27</b></p>
<p class="MsoNormal">Risk Management Framework should be comprehensive within
scope of SSR remit and ICANN’s limited missions. </p>
<p class="MsoNormal"><span style> </span></p>
<p class="MsoNormal">The idea was to be constrained within ICANN’s limited
mission but to be comprehensive within that – but there aren’t any objective
criteria on ‘comprehensiveness’.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Public comments from Verisign and ALAC on Westlake’s
approach to the Risk Management Framework were that it wasn’t comprehensive
enough, within the remit. ATRT2 seems to agree with that view though
acknowledges that comprehensiveness is a matter of opinion.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Anyone have anything to add on this? </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b style>Rec. 28</b></p>
<p class="MsoNormal">ICANN should actively do threat detection and mitigation and
participate in efforts to distribute threat and incident information.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">An ongoing task with engagement with security conferences
and CERTs. Anecdotal feedback says ICANN work on this is helpful. An important
role, that ICANN needs to go on doing. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Agreed? Has SSR RT missed anything here? (I don’t expect so,
just raising the question.) <span style> </span></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span style> </span></p>
<br></div>