I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these (slightly belated - sorry) comments along with any
other Last Call comments you may receive.
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).
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
