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/>