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

Eric Orth <> Tue, 05 May 2020 22:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D219B3A0BEB for <>; Tue, 5 May 2020 15:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 eJ7vZEpfht00 for <>; Tue, 5 May 2020 15:17:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 569F83A0BEC for <>; Tue, 5 May 2020 15:17:30 -0700 (PDT)
Received: by with SMTP id z6so201569wml.2 for <>; Tue, 05 May 2020 15:17:30 -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=mxBB2CCmv/um9spAK0Ip19mWVKvIMwGZFGSHgyGLPGA=; b=el6bp83Gw+7onMLU+gf0VPDFphc+byqQJwC8a4wgZvE47+WBEQz/QIcmwUwijYZBVk ZvqmRisqrD6bxyfuE/3n/0XfZ0FEiGU5aFIaV7xMy6hOBHNCLB4NxoTOAVvZNST9j2r1 2UZF2El7RjY6FddOmHplVzHYrJwLLkODPwFnTbxYND58TywDb1kFjBkVXAhSjqwJ3Jkq z9hqmRHMS9lf0M8+LRnOsU9ixv4xTQSsuWm16Q3iQr2d+MgbbS7ZCtXQ7lxmxZe2Iho7 NDdZfewKtHekMurgaFm5KEGoLWxMntq8dcRmIPRA2j54WxicUhUzwVSjl/y4c3K9Te5z G8ng==
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=mxBB2CCmv/um9spAK0Ip19mWVKvIMwGZFGSHgyGLPGA=; b=ixmJ/w8ZxD+1rP4tTTsyF5HoI6rg8YEeFi5/yNtpE65gLmSJ67RaoL2EtA+ip0NZCo TXvu1EzoFybRQd4evJCjjRIAVodmaRRNQhNdkpaJIrX+KQgd7Gsvt2bJ3KdbhcYfrwrY QQxYyN9o5avEeabeQ5xNtTq38xMoOYqjmsC6saPE1xmmfW0HNF1BLZhKYsRRf7uPM4I1 IyX9/4HdnRts1srAb7mct7IwX6yZ8BWTETaoFSYsiGjExNf+Otc3NoTcyNsd/j5Pxm5d qbW7NZaWQ+5tmzM+BooHAgRSPRhqU0JeP316RPYFTOTslGCZHtxH5sBPILzBZm0sy9BF 8qpQ==
X-Gm-Message-State: AGi0Puai49Tp4Mq6xRAvM88FTjoFz6Q+exZAKAHGbhhC5BGlA4xC+qOL kiZIr4WWptqLPOVSPdkogsq28LFsKMesZjEKVEuYYh+G
X-Google-Smtp-Source: APiQypIcl2f2YNXDbdyQKTdC6+6TpXdamIPwOyECaqE2W32KH686DfCbqWSKhEcq0MBRU/cW4OSaHSr8dphprYLAlaU=
X-Received: by 2002:a05:600c:2c47:: with SMTP id r7mr782910wmg.50.1588717048267; Tue, 05 May 2020 15:17:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Eric Orth <>
Date: Tue, 05 May 2020 18:17:17 -0400
Message-ID: <>
To: Wes Hardaker <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="0000000000004ff3af05a4ee0389"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-15.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: Tue, 05 May 2020 22:17:33 -0000

On Tue, May 5, 2020 at 5:39 PM Wes Hardaker <> wrote:

> Eric Orth <> writes:
> > "As such, EDE content should be treated only as diagnostic information
> and MUST NOT alter DNS
> > protocol processing."
> >
> > (Sorry for not getting back and responding further on this subject in
> > the previous thread.)
> And I'm sorry for delaying getting back to you about you getting back to
> me about me getting...  anyway.
> FYI, at least two of the authors agree with you, as resolvers are
> already making decisions based on unauthenticated information (rcodes).
> But this has been heavily discussed (multiple times) in the WG and the
> conclusion was that EDE cannot alter processing, hence the strong
> language.  So in the end we didn't change the text to soften it, as it
> would counter the decisions of the larger past discussions.

My counterargument is that I feel my objection is more language-based
concerning ambiguity and not counter to the previous WG discussions.  The
general WG consensus was that EDE should be primarily for "diagnostic
purposes".  This draft goes beyond such consensus by banning "altering
processing", a very ambiguous phrase that does not necessarily ban just
non-diagnostic behavior or important decision making, as it could be
debated whether clearly-WG-acceptable alterations such as altering logging
counts as altering processing.

I think the end result of the language as-is is that EDE receivers will
either have to abandon EDE handling entirely to avoid any ambiguous
potential of not being compliant with the spec, or we'll have to just
willfully ignore this newly-added imperative to do whatever processing
alterations we want (hopefully only for diagnostic purposes, but who knows).