Subject: [Gen-art] [Fwd: Re: Gen-art review of draft-ietf-dnsext-dnssec-opt-in-09]

From: Elwyn Davies <[email-masked]>
Date: Fri, 06 Oct 2006 10:03:46 +0100

FYI...

I just realized the conversation after the review didn't make it onto 
gen-art.

I was expecting a revised I-D.

/Elwyn

-------- Original Message --------
Subject: 	Re: Gen-art review of draft-ietf-dnsext-dnssec-opt-in-09
Date: 	Fri, 22 Sep 2006 14:05:57 -0400
From: 	David Blacka <[email-masked]>
To: 	Elwyn Davies <[email-masked]>
CC: 	Mary Barnes <[email-masked]>, [email-masked], 
[email-masked], "Olaf M. Kolkman" <[email-masked]>, Mark Townsley 
<[email-masked]>
References: 	<[email-masked]>

Elwyn Davies wrote:
> 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.

Thanks for the review, Elwyn!

> 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.

Ah.  The ordering is "Canonical DNS Name Order", described in section
6.1 of RFC 4034 (among other places).  Given that familiarity with RFC
4034 is assumed, do you think it would be sufficient to modify the
description only slightly:

  This means that for a RRset or name 'N', the covering NSEC record has
  the name 'N' or has an ownername less than 'N' and "next" name greater
  than 'N' in canonical DNS name order (described in Section 6.1 of RFC
  4034).
?

> 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.

I'm not actually sure what you are getting at here.  The concept
described in this document is (more or less) being standardized as part
of a different effort (NSEC3).  However, there are no current plans
(that I know of) to take *this* experiment and move it to standards
track.  I would assume that if that were to occur, a new document
detailing new algorithm identifiers would be written and standardized.
Anticipating that action in this document doesn't seem particularly
useful to me.  Or have I misunderstood your point?

> 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...

You are correct, this is quite hand-wavy.  The purpose of this sentence
was merely to raise a flag with implementers that the particular
property of Opt-In described in the preceding sentences will most likely
have an impact on their implementation.

I actually do believe that the solution (whatever it may be) would be
obvious to an implementer.

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

The only thing that I can think of is to change the final sentence of
the abstract to:

   This document describes a DNSSEC experiment that allows
   administrators to omit this cryptography and manage the cost of
   adopting DNSSEC with large zones.

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

OK.  I guess I need to make sure that I even know what 'NS' stands for :)

> 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.

Hm. Perhaps not even using the term "delegation-centric" is the right
way to go:

     The cost to cryptographically secure delegations to unsigned zones
     is high for large zones consisting mostly of insecure delegations
     and zones where...

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

OK.

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

OK.

> 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.

Which part, exactly?

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

OK.

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

OK.

> 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).

I'm actually not sure if there is a standard way of writing DNS queries
in RFCs.  This could be written as "Response to query for
WWW.UNSIGNED.EXAMPLE./IN/A"  or just "...WWW.UNSIGNED.EXAMPLE/A".

Again, thanks for the review!

-- 
David Blacka                      <[email-masked]>
Sr. Engineer    VeriSign Infrastructure Product Engineering

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art