Draft:   draft-ietf-dnsext-dnssec-opt-in-09
Reviewer: Elwyn Davies [elwynd@dial.pipex.com]
Review Date: Wednesday 9/20/2006 6:51 AM
IETF LC Date: 9/14/2006

Summary:
This document is almost ready to go as Experimental.  There are a couple 
of places where a little extra explanation might be needed for the 
uninitiated, particularly on the 'covering' relationship which I found 
opaque.  There is also one place (s4.2.3) where there may be a piece of 
hand waving that covers something that is not fully worked out. [Caveat: 
I am not a DNS expert so the examples may conceal undetected bugs.]


Issues/Comments
===============

s1, 'covering NSEC record/RRset':
>
> This means that for
>       a RRset or name 'N', the covering NSEC record has the name 'N', or
>       has an owner name less than 'N' and "next" name greater than 'N'.
>
I don't understand the ordering relationship implied by less 
than/greater than 'N' here.  Having trawled the various DNSSEC 
references I can't see anything that might make understanding of this 
possible.  I think some explanation is needed.

s3: I understand from the proto writeup that something like this 
experiment is quite likely to be standardized in future.  I think I see 
why it would be inappropriate to invoke s7 of the 'DNSSEC experiments' 
draft and allocate public identifiers for the algorithms (on account of 
them being duplicates) but maybe a note about migration to a future 
standard and what this would mean with algorithm identifiers would be 
useful.

s4.2.3:
>
>    Some
>    implementations may have to use new methods for finding these NSEC
>    records.
>
Is leaving this an exercise for the reader/implementer good enough?  It 
may be that it is obvious to one skilled in the art but I sense a hand 
being waved maybe.  Could an example be given of a solution?  OK, its an 
experiment...

Editorial
=========

Abstract: Might be useful to reinforce the fact that it is specifically 
a 'DNSSEC experiment' as this is relevant to its application.

Abstract/s1: Need to expand DNS, NS and NSEC on first appearance.

s2: A small amount of extra explanation of what a 'delegation-centric' 
zone is would help.  I think that some explanation of 'covering NSEC 
records' etc (as mentioned in the issues would also help.  See also the 
comment on s4.2.2.1 below.

s4.1.2,para 2: The 'already' in 'In standard DNSSEC, NSEC records 
already must be returned along with the insecure delegation.' is misplaced.

s4.1.3: s/RCODE=REFUSED/RCODE set to REFUSED/

s4.2.2.1:  I found the words in this section very helpful to my 
understanding of what is going on.  Repeating something like them in s2 
(Overview) would ease understanding of the whole technique.

s4.2.2.2, s4.2.4: s/RCODE=3/RCODE set to 3/

s4.2.4, bullet 2: s/query type/the query type/, s/NSEC record's/The NSEC 
record's/

s6: The 'A' on the end of 'Example A.1: Response to query for 
WWW.UNSIGNED.EXAMPLE.  A' is disconcerting.. is there a better way of 
phrasing this?  (Also applies to the S.1 example in the security section).