[gnso-ff-pdp-may08] Comment Analysis: Items 9a thru 9f

["James M. Bladel" <jbladel@xxxxxxxxxxx>]

Team:

Here are my offered analysis / recommendations for Category 9, items
a-f.  For each recommendation, I posed the following questions:

1.  Has the proposed "next step" been addressed earlier in the report?

2.  If the commenter proposes additional study, is the hypothesis
sufficiently defined and narrowed, such that any results will yield
quantified data? Would the results present a significant opportunity to
inform debate and form a basis for policy?

So, with these in mind, here are the results:

********
9a:  Commentor (Atkinson) recommends that the WG report be reviewed by
the IETF:
Conclusion:  We can invite the IETF to review the final report, and
extend offers to participate in future PDP work in DNS areas of overlap.
 But this can occur out-of-band, and need not be included in our final
report.

9b:  IPC Report encourages this WG (or potentially future WGs?) to
continue work on the subject of Fast Flux, involving additional experts
as necessary.
Conclusion:  Additional work is not ruled out in the report, and is in
fact supported by the suggestions beginning on line 147 and again in the
section beginning on line 810.

9c:  Commentor (Ed) makes three distinct suggestions:  First, ban
affected IPs (responsibility of ISPs). Second, introduce "waiting
periods" between registration and inclusion in the DNS.  Finally, OS and
application developers should not require user intervention when
applying security patches.

Conclusion:  The first recommendation involves the blacklist / whitelist
concept, which is thoroughly addressed in the report.  Also, while
hodling ISPs responsible may or may not be a good idea, it is not within
the scope of an ICANN consensus policy.  The same can be said for the
third suggestion:  Whether or not required, unrefusable security updates
are effective (or legal) is not within the scope of ICANN.    
The second suggestion is potentially within scope, but are addressed in
the report.  (See "rate-limiting," "low TTLS," and the RyC statment
begining on line 2654).

9d:  Commentor (Chamberlain) proposes several recommendations, involving
some variation of the blacklist concept.

Conclusion:  The blacklist / whitelist concepts are thoroughly addressed
in the report.

9e:  Commentor asserts that the root problem is not at the network
layer, but a lack of security in applications, and proposes security
implementations by applications devleopers / users consumate with risk.

Conclusion: Whether or not this would be effective, ICANN cannot mandate
changes to applications developers.

9f:  Commentor (Guiffrida) proposes a black list for illegitimate FF
domains, and a whitelist for legitimate users of the technology.

Conclusion:  The blacklist / whitelist concepts are thoroughly addressed
in the report.
 ******** 


J.