Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

Eric Orth <> Thu, 31 October 2019 19:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D19D11208D9 for <>; Thu, 31 Oct 2019 12:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Status: No, score=-17.499 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, 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 ej-LaLTvKlOc for <>; Thu, 31 Oct 2019 12:08:38 -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 C7226120271 for <>; Thu, 31 Oct 2019 12:08:37 -0700 (PDT)
Received: by with SMTP id w18so7496528wrt.3 for <>; Thu, 31 Oct 2019 12:08:37 -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=AZ9qOlg2lk2D/9dL1XLN+5BgJH4yviVmudkfBRPyS24=; b=AZ/Eiua8OLxb5+6MLw5vBEhe7NHJRtAkCQqi2ZpW9QtH3BJehdHX8CxCbzaaXeGs7v c3VMFedM5ZsG/ybqLgZlw72ITGhhDRKQJRLMKCaihTjQDV5NKn3BPhku5kxgLeyGqekn QbfHLWFatGtspueXkNX3WRDuo3ErFG6eWeIHme3OYxYTALVuI5DxE6g1EKPfmU72eJmh WBpiIb8AQqoYEO8E05n9y1eEOEEYPdz87sDmUuYN8ZSNjK6ohWoHRSD0UUi4AKR+oNZ5 7FkpJouvESpT5y/1T3lVZaZCYapN+pVL9rBNkXnyK6NYSwvMYvYBKmM/pss41f1pgneT Jm1g==
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=AZ9qOlg2lk2D/9dL1XLN+5BgJH4yviVmudkfBRPyS24=; b=Znl9IqzojBrA1XuA3AP1hw8APgjxwcIAiHDE6mN/WWCteYfOAScpYPPHf7HTHLvvrA cJZ08Svw5WmGCmw/P3TVBVtDkpNYbigQ8aRfB3jprwcAuBdRuXlL8CdAAWeoePPh04zI ath/Vat7a0YjsvNgte3iEiLyMO9vZZk5247WW5lYT1KZ6AoPJAq3NsWcHTtbyUXCSwUw Vf3l23V/SPBt44bfAFjvWTTgUHzOIG63aFExouooJ0Hf/g2Zp4CqwboIqQMU+SooHIft LyoBrwqYpDvzaVrjY0jjjOEe7ZckWKtR4jBbU3p/CUno7ooRppOMlRoYPfFq4a5EKqIw WRgQ==
X-Gm-Message-State: APjAAAVLNLXT01rQUd9rAQfRSeFw8On6AmFR2WG0XHYNeNA1gjjOBrSk Ck0BgHLZAk4tNqDcDMAjh06n50nBRMkQwx2zWY3wtAeI
X-Google-Smtp-Source: APXvYqx2qzaASxtZOTV2+wxfABELj7itA4YBocWbBX8OCN9r9bdOQj0TzVUpGjGz/HHCjs7ZrbBwyk+BTh6phEs4p7M=
X-Received: by 2002:adf:ea07:: with SMTP id q7mr7010434wrm.102.1572548915816; Thu, 31 Oct 2019 12:08:35 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Orth <>
Date: Thu, 31 Oct 2019 15:08:24 -0400
Message-ID: <>
To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <>
Cc: dnsop <>,
Content-Type: multipart/alternative; boundary="000000000000854d070596399391"
Archived-At: <>
Subject: Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error
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: Thu, 31 Oct 2019 19:08:40 -0000

On Fri, Oct 25, 2019 at 9:29 AM Petr Špaček <> wrote:

> Would it be possible to get some time allocation of your UX design folks,
> before we set the protocol in stone?

Not likely, unfortunately.  Downside of not having specific plans yet.
Makes it difficult to allocate UX experts.

- Is the current version with "no categorization" okay?
> - Will it be okay in future if dnsop starts adding new codes?
> - Or should we add some inherent categorization into the protocol to make
> it future-proof?
> - If a categorization is needed, what form is best for UX? (please
> suggest!)

Speaking for myself from a non-UX perspective (and I am not a UX expert),
forward compatibility of error codes is a common pitfall in many similar
systems.  Once error receivers start relying on specific error codes to
produce specific essential behavior, expandability often gets locked out
because you can't replace those codes with new ones that receivers might
not immediately recognize.  And having a receiver only know "unknown" error
is usually pretty bad.  Attempts to solve these issues usually involve
stuff like categorization, user-visible messages, and multiple ordered
errors, but my anecdotal experience is that it's pretty rare for such
mitigations to be fully supported by all sides to the level where it
actually helps and expandability still ends up limited.

But specifically to EDE, I think the general circumstances make us fine
without taking any specific steps to mitigate forward compatibility.  It's
mostly been designed just for "supplemental" signalling.  And at least for
the general use cases, eg browsers, I doubt enough recursives will ever (or
be able to) support it for the stub to rely on receiving a recognized EDE.
It will always need to be a nice-to-have with the receiver able to provide
good behavior if no EDE (or an unrecognized new EDE) is received.

So no, I don't think categorization is necessary to make EDE useful.  In
fact, I think it would probably make things more complicated than necessary.