Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

Ondřej Caletka <Ondrej.Caletka@cesnet.cz> Wed, 28 June 2017 11:00 UTC

Return-Path: <Ondrej.Caletka@cesnet.cz>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135DE12EAEB for <dnsop@ietfa.amsl.com>; Wed, 28 Jun 2017 04:00:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
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 F7zoESYxLwfL for <dnsop@ietfa.amsl.com>; Wed, 28 Jun 2017 04:00:32 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEECE12EA64 for <dnsop@ietf.org>; Wed, 28 Jun 2017 04:00:31 -0700 (PDT)
Received: from [IPv6:2001:718:1:6::134:196] (oskarpc.cesnet.cz [IPv6:2001:718:1:6::134:196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 6FCD120066; Wed, 28 Jun 2017 13:00:28 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1498647629; bh=EOGPnhKEs4zxI9UyMnVfxXfcfymoC4Aous1gAUhYNHU=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=RQdjmNlBT90kdk2EHFpIMudVTCsNxlHvRSmJQtAEGxMzaduoedTRjRR165XXOy5uO 7XemP6AE3a6PeP6cBCWBxabwkCiuTNNdbiLttkn86BlD7GKfVXMODh/4fQY5i+UbAz lkMkDrtd9dkD7mHRrg/F0iOQ+pNV+hKi3HM6/LE0=
To: RFC Errata System <rfc-editor@rfc-editor.org>, olafur+ietf@cloudflare.com, pwouters@redhat.com, bclaise@cisco.com, warren@kumari.net, suzworldwide@gmail.com, tjw.ietf@gmail.com
References: <20170623105434.22478B810AB@rfc-editor.org>
Cc: dnsop@ietf.org
From: Ondřej Caletka <Ondrej.Caletka@cesnet.cz>
Message-ID: <15f2db72-8529-6093-2bf1-5af85ee0bca4@cesnet.cz>
Date: Wed, 28 Jun 2017 13:00:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170623105434.22478B810AB@rfc-editor.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms010605040405050909080705"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/H_RhrF_Kbg4vgt1NhU9VaPWavqo>
Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jun 2017 11:00:34 -0000

Hello,

I have an erratum to this reported erratum. This proposed corrected
paragraph:

>    Strictly speaking, the CDS record could be "CDS X 0 X 00" as only the
>    DNSKEY algorithm is what signals the DELETE operation, but for
>    clarity, the "0 0 0 00" notation is mandated -- this is not a
>    definition of DS digest algorithm 0.  The same argument applies to
>    "CDNSKEY 0 3 0 AA=="; the value 3 in the second field is mandated by
>    [RFC4034], Section 2.1.2.

should actually look like this (difference is the first CDS example):

>    Strictly speaking, the CDS record could be "CDS X 0 X X" as only the
>    DNSKEY algorithm is what signals the DELETE operation, but for
>    clarity, the "0 0 0 00" notation is mandated -- this is not a
>    definition of DS digest algorithm 0.  The same argument applies to
>    "CDNSKEY 0 3 0 AA=="; the value 3 in the second field is mandated by
>    [RFC4034], Section 2.1.2.

Otherwise, the statement "only the DNSKEY algorithm is what signals the
DELETE operation" would not make any sense.

--
Regards,
Ondřej Caletka