Subject: Re: [DNSOP] [Ext] Re: Processing error codes in draft-ietf-dnsop-extended-error-10

From: Bob Harold <[email-masked]>
Date: Tue, 1 Oct 2019 15:01:02 -0400

On Mon, Sep 30, 2019 at 8:55 PM Paul Hoffman <[email-masked]> wrote:

> On 9/30/19 7:09 PM, Wes Hardaker wrote:
> > Paul Hoffman <[email-masked]> writes:
> >
> >> Saying "SHOULD NOT" without helping the reading understand the
> >> implications is dangerous and will lead to lack of
> >> interoperability. Either this document specifies the exact places
> >> where an EDE can change the processing of the RCODE, or the current
> >> MUST NOT wording is correct.
> >
> > Did you read the new replacement sentence?
> >
> >        Applications MUST continue to follow requirements from applicable
> >        specs on how to process RCODEs no matter what EDE values is also
> >        received.
> >
> > Is that sufficient?
>
> Yes, thank you.
>
> --Paul Hoffman
>

Just a note.  The original draft had a 'retry' code that was intended to
change how the client reacted.  That has been removed, but there are still
some that would like to 'act on' the EDE.
One reason given for not doing that is that is can be spoofed or changed by
attackers, so it cannot be trusted.  I was hoping that this could improve
some cases where the client is not acting in an optimal way, but I can
understand why that would be discouraged.
Should we warn implementers of the issues, but still not forbid acting on
them?

-- 
Bob Harold

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 01 Oct 2019 16:39:39 -0700

Bob Harold <[email-masked]> writes:

> Just a note. The original draft had a 'retry' code that was intended
> to change how the client reacted. That has been removed, but there
> are still some that would like to 'act on' the EDE.  One reason given
> for not doing that is that is can be spoofed or changed by attackers,
> so it cannot be trusted. I was hoping that this could improve some
> cases where the client is not acting in an optimal way, but I can
> understand why that would be discouraged.  Should we warn implementers
> of the issues, but still not forbid acting on them?

Well, I think the new text tries to do this, no?  Specifically, we're
now saying "follow other specs", but we don't specifically prohibit
not-acting if there are no other specs that intervene.
-- 
Wes Hardaker
USC/ISI