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

[Wes Hardaker <[e-mail]>]

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