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

Eric Orth <ericorth@google.com> Mon, 30 September 2019 18:53 UTC

Return-Path: <ericorth@google.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 855A212006F for <dnsop@ietfa.amsl.com>; Mon, 30 Sep 2019 11:53:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id k4p8B1zM23yV for <dnsop@ietfa.amsl.com>; Mon, 30 Sep 2019 11:53:22 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00EB012001E for <dnsop@ietf.org>; Mon, 30 Sep 2019 11:53:21 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id r5so12505779wrm.12 for <dnsop@ietf.org>; Mon, 30 Sep 2019 11:53:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=gf3rzHK6qYvEBVpU0JwlPgMKGR/TMYed2Wl/3OJofuQ=; b=g8mNIgsSMNhmmGmaXrKvNqRpxHLiNp9/tmeFbZeKMKVlNH+GzTWrSJEKnrCp5JJ04o bh6tjM5HIQb0LIcUI9IpFpbS4BUq6vfakDFFji8wihPypuzvRfqtoeuIneQRmcTOcup0 mGKJOFYQ409VV2VmpxhLMKKOYIm5BZwAut5KfNMJsbhkyBOsrPchloost4dy9jq2AlPQ EJeRnRagQTbYpM3DVOIoxQ80ZN5K4s0vQhwwu6FozvMhcrjEsgmcBgaihw+AdQyFx37e kCUUiVebnZHoDJzJtMSL91/5oi3WqK6oatiOsrai0xR0cvL3Vztjgykm9I2Pfzcl65UM jFkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gf3rzHK6qYvEBVpU0JwlPgMKGR/TMYed2Wl/3OJofuQ=; b=cPCU0Mpkmo48jdODf9ihgu8oiLnYjAVUlwKZq736iTB2SLcSrz8DyoltiG/G+blYjr WDeui5ZayrxAxYHpkzIrJDqXhO8mSxpQIgKOHxJmWfr8oSAOLB6xMSmcGvfDPOP1ijKk sa1e9wjQxe/KBbR9w9gW84GXmw7AMonBJxw78NQGueAfInMKhtROsaMDvg1KEu69DdPK Wv/MUjBwm/ylr7MdXhkjn4skSCOs2rIISJkPkS+lh1Kr1reQnCa+fcjW8UY7wE4HImy9 LRAVzGSc+t91IRDg2MSxDBz6pUOuGV0oPbGylMIOeX/Pn+4DUBcWWfknGHBOJkHauQ1Z ooRQ==
X-Gm-Message-State: APjAAAWIe1TSDMgkyulKlFedKdl0wZhVDnA+mzdjzPDWiEblCusDx92v P1cbSPhNcgU8o2HWCABlHtcSvJ1rSd5LyLn6857YgPtY6h5OWu5a
X-Google-Smtp-Source: APXvYqy3UfYvHR1l2TIZbAf6oiq27fyC62qHv39hp0rrLCFW6ip4Mk8BFf8CYLL33GYqTHQ5on1RgXnsdpnXSxqF4vM=
X-Received: by 2002:a5d:4b46:: with SMTP id w6mr2335880wrs.223.1569869599999; Mon, 30 Sep 2019 11:53:19 -0700 (PDT)
MIME-Version: 1.0
From: Eric Orth <ericorth@google.com>
Date: Mon, 30 Sep 2019 14:53:08 -0400
Message-ID: <CAMOjQcEtDBR29yKmOTvnx-7B7SmC9pox_kzOCKs4jBMQr1VSTA@mail.gmail.com>
To: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="000000000000da5d6a0593c9bf28"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tMasrWQI4qQfCJPEZTsTgsM6g7E>
Subject: [DNSOP] Processing error codes in draft-ietf-dnsop-extended-error-10
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 30 Sep 2019 18:53:24 -0000

I object to the addition of "Receivers MUST NOT change the processing of
RCODEs in messages based on extended error codes." in section 1.  I feel
that it goes too far in limiting options for applications to make use of
the new error codes, and it is too vague for an implementer to know what
processing actions are allowed or not.  As currently written, I do not feel
that Chrome DNS would be able to handle EDEs in any way and be confident of
being spec-compliant.

Regarding the statement being too limiting for implementers, I don't
understand the motivation for such a strong MUST-level restriction.  Maybe
I'm biased as a client-side implementer, but I think we should avoid
restricting application behavior when not relevant to the spec'ed protocol
itself.  If the goal is to prevent applications from misinterpreting the
meaning of RCODE/EDE combinations or making false assumptions about what
combinations may be sent, the spec should clearly state what may be sent
(as it currently does) and what it means.  What an application then does
with that properly communicated information is not relevant to the spec.
If we forbid applications from doing processing based on very reasonable or
obvious interpretations of RCODE/EDE combinations, I think it makes it much
less likely that applications will find value in and implement this spec.

Regarding being too vague, as-written, I do not understand what handling of
EDE is allowed or not in the current draft.  From discussions here, I
assume the intent isn't to prevent an application from reading an EDE and
including it in error logs or error messages to users.  But it's not at all
clear enough for MUST-level statements if that would be changing RCODE
processing or not if such logging and messaging are currently based on
RCODE alone.

My previous comment on this topic (Sept 17) quoted here for reference:

> Any suggestions of making absolute requirements of how the application
> "acts on" EDE codes sounds way too restrictive to me.  Most of how the
> application acts on any error codes is up to the application, and it would
> be unnecessarily limiting to pretend otherwise.  Seems to me it would lead
> to silliness like "this application processes SERVFAIL by sometimes
> continuing to other servers and sometimes not" and then claiming they
> aren't changing that processing by using EDE codes to determine the actual
> continuation behavior.
> Specific thoughts:
> *The text currently in the draft ("systems interpreting the extended error
> codes MUST NOT assume that a combination will make sense") seems
> reasonable.  Not overly restrictive.  Just a reasonable warning of a
> potential false assumption of how the recursive resolver may act.
> *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.
> *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.
> *Something like "applications MUST NOT act on EDE" or "applications MUST
> NOT change rcode processing" does not seem reasonable to me.  Way too
> unclear what "diagnostic" processing is reasonable and allowed or not.  And
> potentially limits applications from doing processing based on very
> reasonable or obvious interpretations of the received rcode/EDE
> combinations.