Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs

[Eric Orth <[e-mail]>]

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.

On Mon, Sep 16, 2019 at 11:20 AM Vladimír Čunát <[e-mail]>
wrote:

> On 9/12/19 8:10 PM, Viktor Dukhovni wrote:
> > SERVFAIL means,  and will continue to mean, I can't help you, better
> luck next
> > time (or elsewhere).
> >
> > The new EDEs are *diagnostic* detail to aid in troubleshoots, but do not
> > override RCODEs.  They are not a more fine-grained RCODE one might "act
> on".
> > If we want more fine-grained *actionable* codes, there's plenty of room
> for
> > more values in the 12-bit EDNS RCODE.
> >
> > [ I chatted off-list with Wes, the above appears to match his take, with
> a bit
> >   luck also rough WG consensus... ]
>
> My understanding was that it was meant for resolvers to change e.g.
> their retrying behavior based on the EDEs in some cases, even after
> removing that "Retry flag".  I did consider that a significant part of
> the (original) motivation, even we did not implement that in the first
> prototype (as only server-side was done).
>
> I certainly agree this issue should better be explicitly stated in the
> final text.  At least assuming the WG consensus will be that they don't
> want resolvers acting on the EDE codes in any way except for diagnostics
> (possibly with RFC2119 qualifier).
>
> --Vladimir
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>