Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191)

Brian Haberman <brian@innovationslab.net> Tue, 02 December 2014 20:21 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F031A6FBE for <dnsext@ietfa.amsl.com>; Tue, 2 Dec 2014 12:21:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCbr_2QzVvts for <dnsext@ietfa.amsl.com>; Tue, 2 Dec 2014 12:21:27 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF5A1A6F0D for <dnsext@ietf.org>; Tue, 2 Dec 2014 12:21:27 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 428A3880EA; Tue, 2 Dec 2014 12:21:27 -0800 (PST)
Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 71BFF71C0002; Tue, 2 Dec 2014 12:21:26 -0800 (PST)
Message-ID: <547E1F3F.5040400@innovationslab.net>
Date: Tue, 02 Dec 2014 15:21:19 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: RFC Errata System <rfc-editor@rfc-editor.org>, weiler@tislabs.com, davidb@verisign.com, ted.lemon@nominum.com, ogud@ogud.com, ajs@anvilwalrusden.com
References: <20141202163646.E4BFC18123F@rfc-editor.org>
In-Reply-To: <20141202163646.E4BFC18123F@rfc-editor.org>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="Crl43d0NQhXQ5i0mFk8QjWKvr9dXWwp3e"
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/ox1OzgO_pMLRXWian7WdhQ2rr6I
Cc: edward.lewis@icann.org, dnsext@ietf.org
Subject: Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2014 20:21:29 -0000

Despite Donald's assertion, I think this is a valid erratum and should
be marked Verified.  However, I will wait for others to chime in on the
subject before doing so.

Regards,
Brian

On 12/2/14 11:36 AM, RFC Errata System wrote:
> The following errata report has been submitted for RFC6840,
> "Clarifications and Implementation Notes for DNS Security (DNSSEC)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6840&eid=4191
> 
> --------------------------------------
> Type: Editorial
> Reported by: Edward Lewis <edward.lewis@icann.org>
> 
> Section: 5.11
> 
> Original Text
> -------------
> ...
> 
> A signed zone MUST include a DNSKEY for each algorithm present in
>       the zone's DS RRset and expected trust anchors for the zone.  The
>       zone MUST also be signed with each algorithm (though not each key)
>       present in the DNSKEY RRset.  
> 
> Corrected Text
> --------------
> A signed zone MUST include a DNSKEY for each algorithm present in
>       the zone's DS RRset and expected trust anchors for the zone.  Each
>       authoritative RRset in the zone MUST be signed with each 
>       algorithm (though not each key) present in the DNSKEY RRset.  
> 
> Notes
> -----
> Zones aren't signed (per se), the data sets within them are.  But not cut point (NS) and glue.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC6840 (draft-ietf-dnsext-dnssec-bis-updates-20)
> --------------------------------------
> Title               : Clarifications and Implementation Notes for DNS Security (DNSSEC)
> Publication Date    : February 2013
> Author(s)           : S. Weiler, Ed., D. Blacka, Ed.
> Category            : PROPOSED STANDARD
> Source              : DNS Extensions
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG
>