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

From: Wes Hardaker <[email-masked]>
Date: Tue, 05 May 2020 14:38:52 -0700

Eric Orth <ericorth=[email-masked]> writes:

> "Because long EXTRA-TEXT fields may trigger truncation, which is undesirable given
> the supplemental nature of EDE.  Implementers and operators creating EDE options SHOULD avoid
> lengthy EXTRA-TEXT contents."

Thanks for pointing that out; it was indeed a failed edit at a different
problem and has been fixed.

> "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.
-- 
Wes Hardaker
USC/ISI

---

From: Eric Orth <[email-masked]>
Date: Tue, 5 May 2020 18:17:17 -0400

> 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).