PERSONAL comments on the FY14 SSR framework
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… Format: 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. Content: 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. Conclusion: 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. mikey Attachment:
smime.p7s |