Re: IESG comments on draft-ietf-dnsext-restrict-key-for-dnssec-03.txt
Dan Massey <masseyd@ISI.EDU> Thu, 12 September 2002 14:56 UTC
Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25658 for <dnsext-archive@lists.ietf.org>; Thu, 12 Sep 2002 10:56:03 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pV7t-000Ftc-00 for namedroppers-data@psg.com; Thu, 12 Sep 2002 07:39:25 -0700
Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17pV7k-000FtM-00; Thu, 12 Sep 2002 07:39:16 -0700
Received: from isi.edu (c1-vpn1.isi.edu [128.9.176.27]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g8CEdEC27572; Thu, 12 Sep 2002 07:39:14 -0700 (PDT)
Message-ID: <3D80A70C.C1183106@isi.edu>
Date: Thu, 12 Sep 2002 10:39:08 -0400
From: Dan Massey <masseyd@ISI.EDU>
Organization: USC/ISI
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Erik Nordmark <Erik.Nordmark@sun.com>
CC: randy@psg.com, ogud@ogud.com, namedroppers@ops.ietf.org
Subject: Re: IESG comments on draft-ietf-dnsext-restrict-key-for-dnssec-03.txt
References: <Roam.SIMC.2.0.6.1031242617.1462.nordmark@bebop.france>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31
X-Spam-Level: *
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Hi, All of the changes discussed below were made and the new draft is now available: draft-ietf-dnsext-restrict-key-for-dnssec-04.txt Thanks, Dan Erik Nordmark wrote: > This document was discussed by the IESG today. > Here are the comments: > > Section 2.1 describes some of the differences between Application Keys > and DNSSEC Keys. However, some of the text (e.g., reasons 3 and > onward) use upper case MUST/SHOULD language in a confusing way. I > suspect the intent is to describe what the existing RFCs require from > these Keys, but it would be better to not use that terminology at all > here (since Application keys are being deprecated, it seems odd for > this document to be saying what one SHOULD do when processing them) > and just describe what the differences are in a more reader-friendly > way. For example: <snip of example text> MUST/SHOULD terms were removed from this section. > > > Sections 4-6 would benefit from similar changes. > > Nits: > > The document sometimes capitalizes "Application key" and > sometimes doesn't. Be consistent? (And shouldn't it then be > "Application Key".) > fixed using "application key". > > uses "isi.edu" rather than "example.com". I don't have a big problem > with this, but should they switch? > fixed using "example.com". > > > with a response that contain the www.isi.edu A record and SIG record. > s/contain/contains/ > > > the SIG and authenticate the www.isi.edu A record. It is typical not > > s/typical/typically/ > fixed > > record. Note that by placing application keys in the KEY record, a > resolver will need the IPSEC, email, TLS, and other key associated > with isi.edu if the resolver intends to authenticate the isi.edu zone > key (since signatures only apply to the entire KEY RR set). > > s/will/would/? I.e., this document is deprecated application keys, so > this should not be "will" it seems. > fixed. -- 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/>
- IESG comments on draft-ietf-dnsext-restrict-key-f… Erik Nordmark
- Re: IESG comments on draft-ietf-dnsext-restrict-k… Dan Massey