Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-08.txt

Shane Kerr <> Mon, 26 August 2019 20:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 076D3120F6F for <>; Mon, 26 Aug 2019 13:17:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jIvT8c97xhHm for <>; Mon, 26 Aug 2019 13:17:09 -0700 (PDT)
Received: from ( [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0B3D120EC1 for <>; Mon, 26 Aug 2019 13:17:08 -0700 (PDT)
Received: from ([2001:470:78c8:2::9]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1i2LQI-0007DG-FU for; Mon, 26 Aug 2019 20:17:06 +0000
References: <> <>
From: Shane Kerr <>
Message-ID: <>
Date: Mon, 26 Aug 2019 22:17:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-08.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Aug 2019 20:17:11 -0000


Thanks for the continued work on this draft!

On 10/08/2019 20.57, Wes Hardaker wrote:
> writes:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Domain Name System Operations WG of
>> the IETF.
> A quick update on the draft status and what big changes are published in -08:
> 1) We removed the rcode binding/copying, after good discussion with
> implementation issues at IETF105.  This turned out to be tricky to
> implement, since in many cases the EDE information is generated before
> an RCODE is actually known.  So the draft is now just a list of un-bound
> info codes.

While I thought the RCODE linkage was a bit clunky, the idea of having 
some structure to the response codes was actually kind of nice, for the 
same reason that the 1xx, 2xx, 3xx, 4xx, 5xx status codes were nice. I 
think the draft is better without using RCODE, but maybe we can pick 
numbers for EDE that are grouped in a similar way?