draft-ietf-dnsext-rfc2539bis-dhk-06.txt

Mike StJohns <Mike.StJohns@nominum.com> Tue, 21 March 2006 22:24 UTC

From: Mike StJohns <Mike.StJohns@nominum.com>
Subject: draft-ietf-dnsext-rfc2539bis-dhk-06.txt
Date: Tue, 21 Mar 2006 17:24:50 -0500
Lines: 90
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_153480983==.ALT"
X-From: owner-namedroppers@ops.ietf.org Tue Mar 21 23:30:23 2006
Return-path: <owner-namedroppers@ops.ietf.org>
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
To: namedroppers@ops.ietf.org
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
X-Message-ID:
Message-ID: <20140418072145.2560.5100.ARCHIVE@ietfa.amsl.com>

As part of the DNSEXT meeting I agreed to review the above document 
with a view to getting it off of the chair's list.  It has passed 
WGLC, but hasn't had sufficient reviewers for AD comfort.

1) The document is currently expired.

2) The document appears to substantially share text with RFC2539 with 
the exception that the specific reference to how to incorporate DH 
data with a KEY record has been replaced with "within the RDATA 
portion of a RR".

3) The document includes text about a "work in progress" that was a 
work in progress back when 2539 was published.  That either needs to 
be removed or cited.

4) There are several nits and warnings on the existing draft (e.g. 
old boilerplate)

For at least some of the same reasons as I cited in for the DSA 
draft, I can't support advancement of this draft.  E.g. there isn't 
enough connective tissue between this document and RFC4034 which 
specifies the various record formats.  To be adequate for 
publication, this document should explicitly cite DNSKEY as the 
record reference and completely specify the part of the RDATA for the 
DNSKEY to which this applies.  Also, the algorithm information 
identifier from 2535 should be added to this document.

Also, the "PublicValue is the binary representation of the DH public 
value with most significant byte first." statement needs to clearly 
identify this is a positive integer (ditto for prime) with no leading 
zero octets or some such. - This is necessary to ensure implementers 
don't accidentally just plug the number into the "BigInteger" 
function and end up with negative numbers of some sort.  In other 
words, the binary representative as stated is ambiguous.

Mike