Mission Failure as a possible outcome

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

Hi Denise,

I'm unable to identify the "Security and Stability" issue in "Fast 
Flux". I'm on that GNSO WG.
I was previously unable to identify the "Security and Stability" issue 
in "domain tasting". I didn't sleep through that one either.
I was also previously unable to identify the "Security and Stability" 
issue in "front running". Nor that one.
I'm perplexed as to the mission of the SSAC as currently staffed, and as 
currently tasked.
A review that omits comment on the SSAC's detour into retail 
enforcement, at the expense of cache hack (caught by someone else, and 
fixed without even nominal mention of ICANN), or the AS prefix hack 
(ditto, and not fixed due to the absence of trust anchors, a subject 
left tbd in Layer 9 for years now), and whatever's coming next, say a 
hack on the time infrastructure, or the cert infrastructure, or ... 
stuff a little bit more important than "fast flux" + "domain tasting" + 
front running" + more of the same, would just tread water.
The rationale for the (current) SSAC implies that it isn't gamed or 
captured by some stakeholder, or worse, a non-stakeholder. This is an 
assumption that is capable of test.
The structure and composition of the (current) SSAC implies that 
security and stability are capable of objective evaluation, and if that 
assumption is incorrect,  the current structure and composition do not 
provide for security and stability to be subjective, and the product of 
compromise by self-interested stakeholders, each with a distinct, and 
equally correct view of security and stability.
The record of the SSAC over the past year is unfortunate, and the "Draft 
Terms of Reference for the Review" should include the possibility of 
concluding that the SSAC as an experiment should be concluded and 
alternatives considered.
Cheers,
Eric