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

[Eric Orth <[e-mail]>]

On Wed, Dec 25, 2019 at 10:36 AM Wes Hardaker <[e-mail]> wrote:

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

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.


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