Subject: [DNSOP] new EDE draft with a few changes

From: Wes Hardaker <[email-masked]>
Date: Wed, 18 Dec 2019 13:11:01 -0800

Folks,

Per the discussions in the past about both the TC bit and
resolver/forwarding, I've updated the draft with the following text for
these two issues.  Below is a new section that describes these issues.
I *believe* that this might be a good enough middle ground to get us
past rough consensus, though I know opinions varied widely on what
people's definitions of "perfect" is.  [the registry ranges are also
updated, but I'm fairly confident we're already at rough consensus for
that.]

Any objections to this path forward?

https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/

diff: https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-extended-error-12&url2=draft-ietf-dnsop-extended-error-13

---

3.  Extended DNS Error Processing

   When the response grows beyond the requestor's UDP payload size
   [RFC6891], servers SHOULD truncate messages by dropping EDE options
   before dropping other data from packets.  Implementations SHOULD set
   the truncation bit when dropping EDE options.

   When a resolver or forwarder receives an EDE option, whether or not
   (and how) to pass along EDE information on to their original client
   is implementation dependent.  Implementations MAY choose to not
   forward information, or they MAY choose to create a new EDE option(s)
   that conveys the information encoded in the received EDE.  When doing
   so, care should be taken to ensure any information is properly
   attributed since an EDNS0 option received by the original client will
   be perceived only to have come from the resolver or forwarder sending
   it.

-- 
Wes Hardaker
USC/ISI

---

From: Eric Orth <[email-masked]>
Date: Mon, 23 Dec 2019 15:39:42 -0500

Regarding TC-bit: I would still prefer adding a sentence or two that error
generators should keep the EXTRA-TEXT field short to minimize the need for
truncation.  I proposed some text for this a month or so back, and I don't
recall any negative feedback about the suggestion.  But if that addition is
controversial, I wouldn't object to the current draft.

Regarding forwarding: Making it implementer-choice generally seems good to
me.  But I am unsure what the current draft means by "properly
attributed".  What is the proper way to attribute an EDE?

On Wed, Dec 18, 2019 at 4:11 PM Wes Hardaker <[email-masked]> wrote:

> diff:
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-extended-error-12&url2=draft-ietf-dnsop-extended-error-13
>
> ---
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 25 Dec 2019 07:36:55 -0800

Eric Orth <[email-masked]> writes:

> Regarding TC-bit: I would still prefer adding a sentence or two that error generators should keep
> the EXTRA-TEXT field short to minimize the need for truncation.

Seems reasonable.  I'll need to go back and find your text since I don't
remember it specifically.  But I'll happily add it.

> Regarding forwarding: Making it implementer-choice generally seems
> good to me.  But I am unsure what the current draft means by "properly

Well, the wording there that we put is was designed to indicate you
should somehow describe where you got the information from.  But we're
not prescribing how, since that's implementation dependent.  Any
suggested text you'd prefer?
-- 
Wes Hardaker
USC/ISI

---

From: Eric Orth <[email-masked]>
Date: Fri, 27 Dec 2019 12:11:17 -0500

> remember it specifically.  But I'll happily add it.

Here is the text I suggested on 2019-12-02: "Long EXTRA-TEXT fields may
cause truncation and bad resolve performance, which is usually undesirable
for the supplemental nature of EDE. Operators setting the field SHOULD
avoid setting unnecessarily long contents, especially when it can be
determined that doing so will cause truncation."

I would suggest adding that to the EXTRA-TEXT definition in section 2, but
maybe it would also be reasonable in the new section 3.

> suggested text you'd prefer?

I think my concern comes from the word "properly" since that implies that
there's a specific prescribed way to do it.  Maybe change the sentence to
something along the lines of "When doing so, the source of the error SHOULD
be attributed in EXTRA-TEXT if doing so is reasonable for the contents of
that field, since an EDNS0 [...]".  Gives a hint of how things can be
attributed while avoiding implying that there's a standardized way to do so.