Document: draft-ietf-dnsext-dnssec-intro-11.txt
          draft-ietf-dnsext-dnssec-protocol-07.txt
          draft-ietf-dnsext-dnssec-records-09.txt

Reviewer: Spencer Dawkins
Date: 26 september 2004 00.48.04 GMT-04:00


Assignment: draft-ietf-dnsext-dnssec-intro-11.txt
           draft-ietf-dnsext-dnssec-protocol-07.txt
           draft-ietf-dnsext-dnssec-records-09.txt


for publication as Proposed Standard.

My perspective: not a Genius of DNS, reading for ease of use of the 
specifications.

The good news: All three of these documents are of high
quality. PROTOCOL and RECORDS are very close. I have one question -
these two documents, taken together, describe the DNSSEC protocol
workings - why do they have two different security sections? (Also,
neither matches INTRO's security section, but that makes more sense to
me - it's probably OK for INTRO to take a broader view.)

All three documents already share a single Acknowledgements section,
and making sure security considerations are consistent and complete is
a lot more important. If these sections are combined into one
occurance, it would be OK to do the same thing with IANA
considerations. But everything else for PROTOCOL and RECORDS is
Auth-48.

The bad news: INTRO is "On the Right Track, but Still Needs Work".

- I can't imagine the RFC Editor or the average reader getting what's
  obsoleted and what's updated right, based on the Introduction. What
  could "this document and its two companions update AND obsolete"
  possibly mean? This section needs a lot more clarity.

- In Section 3, "These services protect against MOST of the threats to
  the Domain Name Service described in" - the authors understand what
  this means a lot better than almost anyone reading it; this is the
  last chance to clearly spell out what's still an exposure.

- NIT - It would be nice to spell out what each record type is at the
  top of page 8, when they are introduced. The authors spell them out
  later, but this is the first place they appear.

- Top of page 9 - this paragraph takes forever to FINALLY say
  "Therefore the receiver must be configured with at least one trust
  anchor" in a very confusing path along the way. The entire
  paragraph, to this point, could be chopped and it would be an
  improvement.

- Section 6 - there's some discussion about problems with recursive
  name servers and proxies, but the problem really seems to be about
  NATs. Which is it? Just needs to be clearer in the second paragraph.

- NIT - Section 7 - It would be nice to show references for SIG(O) and
  TSIG in the second paragraph. It would be nice to spell out "AD bit"
  in the third paragraph.

PROTOCOL NITS

- Last sentence of the abstract - does this document obsolete all
  updates to RFC 2335? If so, better name them out if we expect the
  RFC Editor to get this right (and the readers to understand
  it). (Same comment applies to RECORDS).

- Starting in 3.2.2 there are a few (at least a couple) mentions of
  the "sense of the CD bit". I have no idea what this means, unless
  it's the SETTING of the CD bit. Is this normal terminology in the
  Land of DNS?

- Section 4.2 - s/strips of/strips off/

- Section 5.6, first paragraph - s/example the/example of the/

RECORD had no NITS, except for the "last sentence of the abstract"
(same NIT as PROTOCOL).

The authors deserve special thanks for the excellent examples in
PROTOCOL and RECORDS.