review of draft-ietf-dnsext-dnssec-experiments-02
Andrew Sullivan <andrew@ca.afilias.info> Fri, 10 March 2006 19:00 UTC
From: Andrew Sullivan <andrew@ca.afilias.info>
Subject: review of draft-ietf-dnsext-dnssec-experiments-02
Date: Fri, 10 Mar 2006 14:00:21 -0500
Lines: 68
Reply-To: Andrew Sullivan <andrew@ca.afilias.info>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-From: owner-namedroppers@ops.ietf.org Fri Mar 10 20:11:53 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.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.0
To: namedroppers@ops.ietf.org
Content-Disposition: inline
User-Agent: Mutt/1.5.11
X-SA-Exim-Mail-From: andrew@ca.afilias.info
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
X-Message-ID:
Message-ID: <20140418072141.2560.50646.ARCHIVE@ietfa.amsl.com>
Dear colleagues, I have reviewed the document draft-ietf-dnsext-dnssec-experiments-02. Here are my comments. First, I strongly support the goal of this document. I think it's a good idea to have a well-defined methodology for these experiments. It seems to me that the first bit under 4 could be clarified: The core of the methodology is the use of strictly "unknown" algorithms to sign the experimental zone isn't strictly true, if I'm reading this right, because it isn't the _algorithm_ that is unknown, but its identifier (that seems to be what the clarification in paragraph 6 actually says). I don't think this is a big deal, but it might be worth altering if other changes are being made. Even without the above clarification, however, I would support the document going forward. Nits ==== Section 1, 1st paragraph: Throughout this document, familiarity with the DNS system (RFC1035 [4]) and the DNS security extensions ([1], [2], and [3]. * this doesn't seem to be a sentence. Maybe This document assumes the reader's familiarity with RFC1035 ([4]) and the DNS security extensions ([1], [2], and [3]). Section 9 IANA may need to allocate new DNSSEC algorithm numbers if that transition approach is taken, or the experiment decides to use allocated numbers to begin with. * the antecedent of the "that transition" was a little muddy to me. Here's a suggested replacement, a little verbose: IANA may need to allocate new DNSSEC algorithm numbers in two cases: in case of a successful experiment that elects to move to standards track by the adoption of newly allocated algorithm numbers (as outlined in section 7); and in case the experiment uses allocated numbers to begin with. Best regards, A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada <andrew@ca.afilias.info> M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>
- review of draft-ietf-dnsext-dnssec-experiments-02 Andrew Sullivan