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

Eric Orth <> Mon, 30 September 2019 23:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78D3812008F for <>; Mon, 30 Sep 2019 16:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P_B5Tk147pOh for <>; Mon, 30 Sep 2019 16:02:34 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C4C9120077 for <>; Mon, 30 Sep 2019 16:02:34 -0700 (PDT)
Received: by with SMTP id a11so13173088wrx.1 for <>; Mon, 30 Sep 2019 16:02:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RoP5OQWKV6cGH2TPjSLoQHZENL8MdputZciqqFz/9h8=; b=YBBtOb01v1k0mnch/ZKwE6Uk+DUKwK2mNIkJYksxVW0jv3moetBtKELCxI2TK4oQrl N0KI4/EHuNm7KJF+CMsp0fM+ibXsWYYpdf5r6poY/yAeqLf9LyDEpn1UVLDhb/pP+y0W poA4cPHOADjGVWzC0KKDZDyQ69Z6jteFHnyStie07Uh5fV9eLSjRWiqgE4WDXj+dsFqG J5Nt73p8CbOeJUBZK0n3HuqsnNl3yFugbQN1c9JBc3Qxp651tvy2aeO5ovPXgf0lJwuW 1DgYWhAG0UXGF3W/M1ubLOBn44bboUtp4E2/JpSJ2kdoaATHqQ5m+y/MUomLI1XLS6XI TeKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RoP5OQWKV6cGH2TPjSLoQHZENL8MdputZciqqFz/9h8=; b=sY2LJoMZhMA1NxX4mST6eFXxtavBsDp3uEHaqyJegQoP8ProkMQuH4+Poe7tOqTgRN rMeLaW3/paJrP/dSBeQUYLFckVLGPf/cMWlBLHtp2aO2gLot2MKepgtVxylPbyi+PTjX lDsBy5fyi5ye2XLtKMKUIByTGLcnqi2KySty4uoz+NrwkmjpyOMswtcqAMklEthIAGff 7PmEMMDn/pWUlVFAEaPj6yklArLvFUa1w3PUAus8WWkmTvE5ik8i78DJ5g5yCsKqDZJD gr8QkxL6DyHzsqTFBe5abc/DZBnVYugN2oLSsQxbGzCA82cR53IjEY9FWh/qGuygYkDB wOIw==
X-Gm-Message-State: APjAAAVrfIxyeRE7bF+2xRixobHuXW38iZs3LvtLqU1y4wc5Vcb+5f5o Oyhk04QE/o4sMka9Eo+N6kpwX5KUFHBezvJw+IpoSHtKJ/xY77Ki
X-Google-Smtp-Source: APXvYqxawfmNZIlQ/v0Vh+lO2Fb/tlDVCf7lkEcfJbFD10uRFcdtOTEQoTT+UhM/X9gBUmOvt17H2xq/X7KX4RCP8jk=
X-Received: by 2002:adf:d1a8:: with SMTP id w8mr14476077wrc.271.1569884552311; Mon, 30 Sep 2019 16:02:32 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Eric Orth <>
Date: Mon, 30 Sep 2019 19:02:20 -0400
Message-ID: <>
To: Paul Hoffman <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000147f670593cd3b3f"
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:02:37 -0000

On Mon, Sep 30, 2019 at 5:40 PM Paul Hoffman <> wrote:

>  From RFC 2119:
> 4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
>     there may exist valid reasons in particular circumstances when the
>     particular behavior is acceptable or even useful, but the full
>     implications should be understood and the case carefully weighed
>     before implementing any behavior described with this label.
> 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.
> It is feeling like there is widespread confusion about the purpose of
> EDEs. 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. It
> would be really good if there was a list of which EDEs might be used to
> change specific RFCs so that the WG can understand this better. In
> specific, the core DNSSEC RFCs specify how to handle certain RCODEs in
> certain circumstances with MUST-level requirements. Does this document
> change those requirements?

I think this is where something along the lines of my previous suggestion
would be helpful ("applications MUST continue to follow requirements from
applicable specs on how to process rcodes no matter what EDE is also
received"), especially if an attempt is made to reference such other-RFC
requirements.  I don't think anybody has intentionally suggested that this
draft should override or remove RCODE processing required by other RFCs.

In general, I think EDEs should not change (remove, override, *or add to*)
any current requirements for RCODE processing.  But the current language on
"MUST NOT change the processing of RCODEs" seems to add to requirements by
controlling how an application acts even in ways that are not currently
restricted or defined.  It's not "MUST NOT change *required* processing",
so it seems to be adding an odd requirement that an implementation keep
doing exactly what it was doing before whether required by other RFCs or

Making a restriction that can ambiguously be read as disallowing an
implementation from doing anything with an error code seems like a good
recipe for all potential implementations to ignore the error code in all
cases and not even use it for simple diagnostic purposes.