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

[Eric Orth <[e-mail]>]

Both additions look good to me.  Thanks.

On Wed, Jan 15, 2020 at 12:00 PM Wes Hardaker <[e-mail]> wrote:

> Eric Orth <[e-mail]> writes:
>
> > 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."
>
> Excellent, thanks.  I've adapted it to the following:
>
>     <section title="Extended DNS Error Processing">
>       <t>When the response grows beyond the requestor's UDP payload
>       size <xref target="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.  Long EXTRA-TEXT fields may trigger truncation, which
>       is usually undesirable for the supplemental nature of
>       EDE. Implementers and operators creating EDE options SHOULD avoid
>       setting unnecessarily long EXTRA-TEXT contents to avoid
>       truncation.</t>
>
> Hopefully you're ok with that?
>
> >     > 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?
> >
> >     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?
> >
> > 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.
> >
>
> I like that, but shortened it a bit to:
>
>       When doing so, the source of the error SHOULD be
>       attributed in the EXTRA-TEXT field, since an EDNS0 option
>       received by the original client will be perceived only to have
>       come from the resolver or forwarder sending it.
>
> Sound ok?
>
> --
> Wes Hardaker
> USC/ISI
>