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
- draft-ietf-dnsext-rfc2539bis-dhk-06.txt Mike StJohns
- RE: draft-ietf-dnsext-rfc2539bis-dhk-06.txt Eastlake III Donald-LDE008