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

Wes Hardaker <> Mon, 30 September 2019 23:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CEE312008F for <>; Mon, 30 Sep 2019 16:09:25 -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 hgkBnzEldvyK for <>; Mon, 30 Sep 2019 16:09:24 -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 ED1AA120077 for <>; Mon, 30 Sep 2019 16:09:23 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTPA id 38BA022DB9; Mon, 30 Sep 2019 16:09:23 -0700 (PDT)
From: Wes Hardaker <>
To: Paul Hoffman <>
Cc: "dnsop\" <>
References: <> <> <>
Date: Mon, 30 Sep 2019 16:09:23 -0700
In-Reply-To: <> (Paul Hoffman's message of "Mon, 30 Sep 2019 21:40:33 +0000")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [DNSOP] [Ext] Re: 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 23:09:26 -0000

Paul Hoffman <> writes:

> Saying "SHOULD NOT" without helping the reading understand the
> implications is dangerous and will lead to lack of
> interoperability. Either this document specifies the exact places
> where an EDE can change the processing of the RCODE, or the current
> MUST NOT wording is correct.

Did you read the new replacement sentence?

      Applications MUST continue to follow requirements from applicable
      specs on how to process RCODEs no matter what EDE values is also

Is that sufficient?

> Some folks (apparently including the document authors) want to be be
> able to use the presence of an EDE to change the way resolvers act.

Not sure why you think the authors think that.  We've (I think all) been
arguing "this is for debugging".  I do push back on unnecessary MUSTs a
lot of the time, but I think the above text is better and still uses
strong language and indicates precedence goes to other specs.

Wes Hardaker