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

From: Eric Orth <[email-masked]>
Date: Mon, 30 Sep 2019 14:53:08 -0400

I object to the addition of "Receivers MUST NOT change the processing of
RCODEs in messages based on extended error codes." in section 1.  I feel
that it goes too far in limiting options for applications to make use of
the new error codes, and it is too vague for an implementer to know what
processing actions are allowed or not.  As currently written, I do not feel
that Chrome DNS would be able to handle EDEs in any way and be confident of
being spec-compliant.

Regarding the statement being too limiting for implementers, I don't
understand the motivation for such a strong MUST-level restriction.  Maybe
I'm biased as a client-side implementer, but I think we should avoid
restricting application behavior when not relevant to the spec'ed protocol
itself.  If the goal is to prevent applications from misinterpreting the
meaning of RCODE/EDE combinations or making false assumptions about what
combinations may be sent, the spec should clearly state what may be sent
(as it currently does) and what it means.  What an application then does
with that properly communicated information is not relevant to the spec.
If we forbid applications from doing processing based on very reasonable or
obvious interpretations of RCODE/EDE combinations, I think it makes it much
less likely that applications will find value in and implement this spec.

Regarding being too vague, as-written, I do not understand what handling of
EDE is allowed or not in the current draft.  From discussions here, I
assume the intent isn't to prevent an application from reading an EDE and
including it in error logs or error messages to users.  But it's not at all
clear enough for MUST-level statements if that would be changing RCODE
processing or not if such logging and messaging are currently based on
RCODE alone.

My previous comment on this topic (Sept 17) quoted here for reference:

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

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 30 Sep 2019 13:53:55 -0700

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

> I object to the addition of "Receivers MUST NOT change the processing
> of RCODEs in messages based on extended error codes."

Actually, I agree with you.  That text was from suggestion and I put it
in unaltered.  I thought about changing it to a SHOULD NOT.

> doesn't pretend that the EDE spec now tells the application what to do in

I think your point is valid and follows the intent: EDE is *not*
supposed to supersede other specifications that specify how to process a
DNS response.

> *Something like "applications SHOULD interpret EDE as supplemental to rcode
> rather than as a replacement" also seems reasonable.  Clarifies the

Again, makes sense.  I think it's covered by your other sentence though?
(which I've just replaced the previous sentence with)

-- 
Wes Hardaker
USC/ISI

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Sep 2019 21:40:33 +0000

> in unaltered.  I thought about changing it to a SHOULD NOT.

 From RFC 2119:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
    there may exist valid reasons in particular circumstances when the
    particular behavior is acceptable or even useful, but the full
    implications should be understood and the case carefully weighed
    before implementing any behavior described with this label.

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.

It is feeling like there is widespread confusion about the purpose of EDEs. Some folks (apparently including the document authors) want to be be able to use the presence of an EDE to change the way resolvers act. It would be really good if there was a list of which EDEs might be used to change specific RFCs so that the WG can understand this better. In specific, the core DNSSEC RFCs specify how to handle certain RCODEs in certain circumstances with MUST-level requirements. Does this document change those requirements?

--Paul Hoffman

---

From: Eric Orth <[email-masked]>
Date: Mon, 30 Sep 2019 19:02:20 -0400

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

> 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.
>
> It is feeling like there is widespread confusion about the purpose of
> EDEs. Some folks (apparently including the document authors) want to be be
> able to use the presence of an EDE to change the way resolvers act. It
> would be really good if there was a list of which EDEs might be used to
> change specific RFCs so that the WG can understand this better. In
> specific, the core DNSSEC RFCs specify how to handle certain RCODEs in
> certain circumstances with MUST-level requirements. Does this document
> change those requirements?
>

I think this is where something along the lines of my previous suggestion
would be helpful ("applications MUST continue to follow requirements from
applicable specs on how to process rcodes no matter what EDE is also
received"), especially if an attempt is made to reference such other-RFC
requirements.  I don't think anybody has intentionally suggested that this
draft should override or remove RCODE processing required by other RFCs.

In general, I think EDEs should not change (remove, override, *or add to*)
any current requirements for RCODE processing.  But the current language on
"MUST NOT change the processing of RCODEs" seems to add to requirements by
controlling how an application acts even in ways that are not currently
restricted or defined.  It's not "MUST NOT change *required* processing",
so it seems to be adding an odd requirement that an implementation keep
doing exactly what it was doing before whether required by other RFCs or
not.

Making a restriction that can ambiguously be read as disallowing an
implementation from doing anything with an error code seems like a good
recipe for all potential implementations to ignore the error code in all
cases and not even use it for simple diagnostic purposes.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 30 Sep 2019 16:09:23 -0700

Paul Hoffman <[email-masked]> writes:

> 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?

> Some folks (apparently including the document authors) want to be be
> able to use the presence of an EDE to change the way resolvers act.

Not sure why you think the authors think that.  We've (I think all) been
arguing "this is for debugging".  I do push back on unnecessary MUSTs a
lot of the time, but I think the above text is better and still uses
strong language and indicates precedence goes to other specs.

-- 
Wes Hardaker
USC/ISI

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 Oct 2019 00:54:54 +0000

>        specs on how to process RCODEs no matter what EDE values is also

Yes, thank you.

--Paul Hoffman