Security, Stability & Resiliency of the DNS Review Team (SSR RT)

[Andrew Sullivan <asullivan@xxxxxxx>]

Dynamic Network Resources, Inc. (Dyn) appreciates the opportunity to
review and respond to the Security, Stability, and Resiliency Review
Team Report Public Discussion Draft #1.

We have read the draft posted for public comment.  We offer these comments.

On the whole, the Draft makes recommendations with with we agree.  We
find compelling the way the report sets out an argument and set of
considerations, and then makes a specific recommendation based on
those considerations.

We are a little concerned that the terms "Security", "Stability", and
"Resiliency" do not seem to be prominently or independently defined
for the purposes of the report.  The effect of this is seen
throughout, because the meanings of the terms seem to wax and wane
depending on the topic.  (For instance, do IDNs and IDN variants
affect the stability of the DNS?  In the strict sense, depending on
how they are implemented, obviously not: they're just another label in
the DNS.  Yet 4.2.6.3 says they present a stability issue.)

We do not understand recommendation 8 or the section 4.2.1.2 that
precedes it.  It appears to be suggesting tightening of the
relationship between the SSR Framework and the Strategic Plan, but the
text suggests that they are in close alignment.  We do not understand
what problem is to be solved here.

We have some concerns about recommendation 9, which might be
interpreted to suggest that ICANN seek formal certification for ICANN
processes.  Despite the fact that the Internet and the DNS are
critical infrastructure, it is clear to us that, today, almost all of
the people in the world competent to understand or implement root zone
operations are in fact engaged in that activity, or else are involved
in the closely-related task of providing such infrastructure at other
levels.  Even if we wished it otherwise, there is no certification
authority competent to certify ICANN's processes, and who is not also
already engaged in the same processes.  We would be extremely
uncomfortable with the introduction of process certifications for
these operations where such certifications were developed by anyone
other than those affected parties.  Certifications are most convincing
when they are developed by completely disinterested bodies competent
in the domain of expertise.  Today, such bodies don't exist.  We
recommend that the RSSAC instead undertake some internal evaluation of
best practices, and publish the results.  This is peer-certification;
but it is the best that can be hoped for today.

Recommendation 23 is about providing appropriate resources to RSSAC
and SSAC, and in making sure they are not subject to pressure.  But a
significant part of the reasoning depends on the observation that, too
often, ICANN asks people to perform evaluations in unreasonably short
times.  This problem -- it has been a problem for many years, and has
been recently made worse with the new two-step public comment period
-- is a serious and significant one.  It ought to receive attention in
its own right, for it is, in our view, at least as bad as any other
problem of SSAC or RSSAC having inadequate resources.  Of all the
"resources" we can think of, time is the most precious; it's also the
one ICANN public processes seem most inclined to sacrifice.  It is
worth considering that these time pressures might be alleviated to
some degree by organizing work around topics rather than
constituencies.  For instance, the SSR RT2 report is but one of three
current special activities within ICANN alone -- leaving aside SSAC
and RSSAC -- directed at the security and stability of the DNS.  The
report actually notes this indirectly, suggesting greater clarity in
the roles of SSAC and RSSAC.

We thank the Review Team for a comprehensive draft report.  We hope
that these modest suggestions may be of service in its preparation of
a final report.

Sincerely,

-- 
Andrew Sullivan
Dyn Labs
asullivan@xxxxxxx