ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

PERSONAL comments on the FY14 SSR framework

  • To: comments-ssr-fy14-06mar13@xxxxxxxxx
  • Subject: PERSONAL comments on the FY14 SSR framework
  • From: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Date: Wed, 17 Apr 2013 17:58:36 -0500

hi all,

i'm sitting down to draft these comments just three days before the deadline so 
these will have to be personal comments i'm afraid.  thus the trademark Mikey 
lower-case look and feel…


i think the shift from Powerpoint slides to narrative text makes for a more 
substantive document.  i really appreciate the work that had to go into that 
transformation, and think that this is the right direction for future versions 
of the framework.  the bad news is that it also highlights some areas that are 
still unclear and need continued refinement.  but having a narrative text makes 
a much better foundation on which to base that conversation.

the overall flow of the document is still quite choppy.  if i were to guess, 
i'd bet that this draft is the product of one author working under considerable 
time/resource pressure.  the document would benefit from "another set of eyes" 
to normalize the level of detail (which ranges, sometimes quite abruptly, from 
very general to very granular).  i'd also have somebody take a look at the 
overall organization of the document -- there are pieces that i was looking for 
in one part of the document that appear in another.  suggestion: have a copy 
editor take a pass through the document for readability, style and consistency.

i'd like to amplify Dyn's comment -- the cartoon graphics do not stand on their 
own.  while they're great conversation-starters and are probably useful for 
introduction/overview discussions, they raise many topics that then need more 
detailed treatment in the narrative.  suggestion: build out a narrative that 
describes each section of the cartoon diagram.


roles and responsibilities are still unclear in some cases, and unsatisfying in 
others.  as you know from previous comments, i am quite keen to see clearer 
definitions of, and boundaries between, the SSR roles, responsibilities and 
accountabilities of "ICANN the corporation", "ICANN the community" and 
"everybody else."  i'm happy to note that these distinctions are starting to 
show up in this document, but i still think there's a long way to go towards 
really understanding those relationships and documenting those understandings.  
suggestion: acknowledge somewhere in this draft that the role-definition is 
work is not yet complete, and better yet lay out a path/plan as to how we're 
going to get there.

another lingering question that i have for ICANN with regard to SSR is where is 
the focus?  one of the things that the cartoons highlight for me is the vast 
breadth and nature of the work that the ICANN security team, and community, 
performs.  here again the switch to a narrative form is a two-edged sword.  the 
good thing is that we see a bit more detail about all the meetings attended and 
presentations made.  but at the same time that list highlights how much the 
ICANN security team is getting pulled in many different directions.  as i read 
that section, i start to wonder how the choices are made between all the 
activities on the cartoon chart.  suggestion:  build in answers to the 
following questions: what gets priority?  who chooses?  on what basis?  and, 
again to echo Dyn, what's the impact of "matrix management" and "agile 
delivery" going to be on all that?

Cases in point:

finally, i'd like to throw a few case-study issues at this model and ask how 
they fit.  three interesting ones surfaced during the discussion in Beijing and 
i'm curious to see if this plan can address them, or if they need to get taken 
to a different place.  here's the list:

- the SAC45 recommendation (never implemented) that high-frequency invalid 
strings at the root (eg. .home, .corp, .local, etc.) be prohibited from 
delegation via RFC 2606.
- the need to the prohibit delegation of 2nd level names in new gTLDs for 120 
days after gTLD contract signing to allow time for internal certs. to be 
revoked as described in SAC57
- the collision between the desires of IDN applicants to quickly get to market 
and the findings in section 5 of the report "User Experience Implications of 
Active Variant TLDs"

in all three of these cases i think there is a profound issue -- ICANN (the 
corporation AND the community) is transferring substantial risk to end users of 
the DNS without asking their permission or telling them what the consequences 
will be.  i think that the SSR framework should provide us some insight as to 
how to proceed with matters like these.  unfortunately, i think the framework 
falls short in this regard.  in the case of SAC45, those recommendations have 
been out there for three years and have not been acted on, as evidenced by the 
fact that there are applicants for two of the high-frequency error strings 
(.home and .corp).  in the case of IDN variants, one Beijing participant 
summarized the situation by saying "these are just like building an airplane 
with the round part of the wing on the bottom -- they just won't work."  
shouldn't there be some clue in the SSR Framework as to who should be 
addressing issues like this?  aren't we falling short of our SSR responsibility 
if we just stand idly by?  suggestion: take these three issues and describe how 
they should be addressed in the the context of this SSR framework.


thanks to all who helped put this framework together.  overall i put it in the 
"much improved" category.  but there is still plenty of room to do better.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy