Re: [DNSOP] Processing error codes in draft-ietf-dnsop-extended-error-10

Wes Hardaker <> Mon, 30 September 2019 20:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29BED12016E for <>; Mon, 30 Sep 2019 13:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aFsRSlNp6Cpp for <>; Mon, 30 Sep 2019 13:54:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0273D120143 for <>; Mon, 30 Sep 2019 13:54:04 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTPA id F414D29A06; Mon, 30 Sep 2019 13:53:55 -0700 (PDT)
From: Wes Hardaker <>
To: Eric Orth <>
References: <>
Date: Mon, 30 Sep 2019 13:53:55 -0700
In-Reply-To: <> (Eric Orth's message of "Mon, 30 Sep 2019 14:53:08 -0400")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] Processing error codes in draft-ietf-dnsop-extended-error-10
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, 30 Sep 2019 20:54:07 -0000

Eric Orth <> writes:

> I object to the addition of "Receivers MUST NOT change the processing
> of RCODEs in messages based on extended error codes."

Actually, I agree with you.  That text was from suggestion and I put it
in unaltered.  I thought about changing it to a SHOULD NOT.

But, I like some of your suggestions:

> *Something like "applications MUST continue to follow requirements from
> applicable specs on how to process rcodes no matter what EDE is also
> received" also seems reasonable.  Clarifies that those cases where
> requirements do exist on how an application acts on errors still apply but
> doesn't pretend that the EDE spec now tells the application what to do in
> all cases.

I think your point is valid and follows the intent: EDE is *not*
supposed to supersede other specifications that specify how to process a
DNS response.

> *Something like "applications SHOULD interpret EDE as supplemental to rcode
> rather than as a replacement" also seems reasonable.  Clarifies the
> communicated meaning of the code without over prescribing how the
> application acts on that meaning.

Again, makes sense.  I think it's covered by your other sentence though?
(which I've just replaced the previous sentence with)

Wes Hardaker