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

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 <wjhns1@hardakers.net> wrote:

>
> 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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>