PERSONAL comment from Mikey O'Connor

["Mike O'Connor" <mike@xxxxxxxxxx>]

hi all,

i note, with disappointment that i'm sure is shared by the hard-working members 
of the SSR-RT, that there are very few comments on your important work.  i 
wasn't planning to comment, since i'm in transition between constituencies and 
didn't have time to draft comments for approval by my fellow co-chairs of the 
DSSA.  but your work took too much time and is too good to go uncommented on.  
so these are entirely personal comments, in standard Mikey lower-case format to 
drive that point home.

first and foremost, CONGRATULATIONS to the whole group on a fine job.  like all 
the other ATRT efforts, the first one will always be the hardest -- subsequent 
teams will have a much easier time walking down the path that has been carved 
out by you first-timers.  so a hearty "way to go" to all who participated in 
the effort.

i feel compelled to comment (personally, remember, this is personal-comment 
only) on the references to the DSSA throughout the report, partly because 
there's an implied presumption that the DSSA will be an ongoing effort when in 
fact we have a sunset baked into our charter.  that sunset may be at the end of 
our first-pass effort which we're on track to publish for review at Prague, but 
for sure it'll be at the end of our more-detailed second-pass (presuming we get 
a green light to go deeper from our respective AC/SOs).  so we all need to 
spend some time thinking about what happens after the DSSA members drink that 
final beer at the end-of-project party.  that said, it's gratifying to see that 
our work noted and appreciated in your report.  
  
i love the emphasis on best practices and outreach in the report.  here's a 
list of four strategic goals for that activity which might be incorporated into 
the recommendation, and which could be used to describe the value of the 
activity to all participants in the DNS/security/management ecosystem/community 
(these are generic goals that work for any business anywhere, btw -- but 
they're useful when trying to develop the business-case for doing something);

-- get more nimble
-- improve quality
-- increase revenue/value
-- reduce costs

i actually laughed out loud when i hit the "budget" part of the report.  you 
are DEFINITELY on to something there.  i quizzed the ICANN CFO about the 
financial systems at the Brussels meeting (i think) and realized that ICANN was 
(is?) running a financial system that wasn't very well-suited to 
program-management record keeping.  that's one of the underlying reasons why it 
was so hard for you to match the budget back to the expenditures.  so all i can 
say to that section is "yea verily" but realize that this is an 
organization-wide puzzler, not just limited to the security area.  

i thought Compliance got short-shrift in the document -- audit/compliance is a 
really important part of a security management system.  i'm convinced that 
Compliance is still in need of a big upgrade -- across the board, not just 
resources.  interestingly, the views of the major Registrars and the GNSO 
non-contracted house are pretty closely aligned here.  Compliance probably 
needs to get moved out from under Legal (conflicting goals), redirected away 
from tools and process toward doing more actual compliance/enforcement work, 
given a shake at the leadership level to raise their sights, etc.  they're 
still way too hesitant and way too quick to say "not our job" or "here's why we 
can't do that."  so a bit more pointed discussion of the audit/compliance 
portion of risk management would be a Good Thing in my view.

i liked the "future risk" discussion a lot.  i think the you kinda tiptoed 
around the "interventions outside the process" issue.  ill-informed (or 
consciously malicious) actions by governments and regulators are a 
threat-source in my view and have started showing up in threat-scenarios 
developed by others as well.   i think  there needs to be more focus on 
mitigating that threat, mostly at the diplomatic/political layer.  technical 
security people will have a hard time addressing that one.  so it seems to me 
that responsibility and accountability for addressing some of these issues 
needs to be elevated in priority and visibility.

finally, i found the whole discussion of the history of the movement/placement 
of the risk-management framework within ICANN fascinating.  i think it would be 
useful to sharpen up the meaning of "risk management framework" in the 
document.  i know, i know, i can hear you saying "it's not defined yet so how 
can it be better defined??" but to a certain extent that's what i was trying do 
with a couple of the slides we built for our DSSA conversation with you in 
Dakar -- showing the little-tiny "risk assessment" piece that we're working on 
in the DSSA vs the great-big "risk management" pile that risk-assessment is but 
a part of.  i think we'll do a darn fine job of defining the risk-assessment 
framework in the DSSA.  and that will plug in nicely to the larger thing -- but 
a description of *what else* is in that larger thing (even if it's not terribly 
well defined yet) would be a useful thing for you to do in your final report.

again, my apologies for the slap-dash informal comments that haven't been 
vetted by anybody.  but your report is a great start and deserves comments.  i 
hope a many more are coming soon.

mikey

- - - - - - - - -
phone   651-647-6109  
fax             866-280-2356  
web     http://www.haven2.com
handle  OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)