<<<
Chronological Index
>>> <<<
Thread Index
>>>
PERSONAL comment from Mikey O'Connor
- To: ssrt-draft-report@xxxxxxxxx
- Subject: PERSONAL comment from Mikey O'Connor
- From: "Mike O'Connor" <mike@xxxxxxxxxx>
- Date: Thu, 12 Apr 2012 19:54:32 -0500
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.)
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|