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:04:31 +0100

For the record...

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

David Blacka wrote:
> 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).
> ?
>   
Maybe using 'comes before' or 'comes after' in the canonical name order 
since the greater/less than assumes you are used to dealing with order 
relationships in mathematics.  I guess it doesn't need to be spelt out 
that the implication of this is that one will have less/more components 
than the other - the ordering would allow for names with the same number 
of components to be compared but that is not what is meant.

Probably what should be said is that using the canonical name ordering, 
the most significant part of the name that comes after must  be the same 
as the the name that comes before (i.e., if the name that comes before 
has x component labels then the x most significant labels of the one 
that comes after must be the same as the name that comes before - 
symbols would help!).

I'm sure there must be a better way to say this.. something about sub 
domains perhaps.
>   
>> 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?
>   
The point of s7 in DNSSEC experiments is to try and minimize the pain if 
the experiment eventually goes to standard in some form.  If the 
algorithm identifiers are not changed, then people who were 
participating in the experiment could transition more seamlessly.  I am 
not sure if that would be relevant between this experiment and the 
eventual NSEC3 stuff.  s7 means that you could potentially ask for 
permanently allocated but different identifiers rather than using the 
experimental range if it would minimize the eventual pain of transitioning.
>   
>> 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.
>   
You can fight this one out with the wg/IESG!  I have no idea.
>   
>> 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.
>   
Just put in the draft identifier to be replaced by a non-reference 
number '(RFCxxxx)' after 'DNSSEC  Experiment'.
>   
>> 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?
>   
The whole section! But specifically the words at the end of the two 
bullet points helped quite a bit rather than the more abstract 
formulation in the overview.
>   
>> 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".
>   

Neither am I.  'Querying for A record in EXAMPLE...'

/Elwyn
> Again, thanks for the review!
>
>   

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