ICANN ICANN Email List Archives


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

Dyn's comments on DNS SSR RT final report

  • To: ssr-rt-final-report@xxxxxxxxx
  • Subject: Dyn's comments on DNS SSR RT final report
  • From: Andrew Sullivan <asullivan@xxxxxxx>
  • Date: Mon, 30 Jul 2012 12:12:27 -0400

Dynamic Network Services, Inc (Dyn) is pleased to have the opportunity
to comment on the "Final Report of the Security, Stability and
Resiliency of the DNS Review Team".  We have read this report, and
hereby submit our remarks.

We were initially a little intimidated by a report that stretched to
28 recommendations.  Our concern was that the recommendations would
turn out to be vague recommendations that were unimplementable.  We
were pleasantly surprised.  On the whole, these recommendations are
sensible, carefully crafted, and specific.  The related discussion for
the recommendations also sticks to the point, and it is not difficult
to see why a given recommendation follows from the discussion.  This
is a good report.  We commend the Review Team for its work.

We wish especially to commend the way the report's recommendations
appear to be implementable without being so particular as to
constitute operational instructions.  We like the report's emphasis on
clear or, where appropriate, measurable outcomes.

We think two recommendations are particularly worthy of attention and
further comment.  In both cases, it is to emphasize the report's
The first is Recommendation 9.  If one reads only the recommendation,
one might form the impression that it presumes all or most of ICANN's
areas of responsibility are subject to certification, and that pursuit
of such certification would be a wise idea.  The discussion in the
body of the document, however, is more nuanced.  Some things that
ICANN does are, by their nature, unique: there is only one DNS root.
It would be absurd to standardize the function of populating it, for
what other instances of doing it would be useful for comparison?
Second, the report does not actually advocate pursuing certification
for its own sake, but instead only where an ICANN function is
substantially the same as functions that are already well-understood.
Any action with respect to implementing Recommendation 9 should be
careful to take into account the limitations in the report's
discussion of the topic.

The second is Recommendation 20.  The recommendation in itself ought
to be self-evident.  But there are two things we want to emphasize.
First, as the discussion in the report's text makes clear, the
information necessary to evaluate a planned course of action simply
has to be available.  Second, even if the information is actually
available, that availability is not in itself enough.  Transparency
requires that those who are interested have a hope of understanding
the information as well.  Too often people act as though the mere
availability of information qualifies as transparency.  Simply
publishing everything isn't adequate: transparency requires that
interested parties can understand the information.

Respectfully submitted,

Andrew Sullivan
Dyn, Inc.

Andrew Sullivan
Dyn Labs

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

Privacy Policy | Terms of Service | Cookies Policy