Hackathon feedback

[each]

Stephane Bortzmeyer worked on implementing EDE in Knot the hackathon in Prague, and mentioned a few issues that came up:

1. INFO-CODE bit layout was a bit ambiguous as it's a 12-bit field and "byte order" isn't meaningful. The packet layout diagram helps, but we could help by specifing in the text that the combined response and info fields are two octets in network byte order, and RESPONSE-CODE is the most significant four bits and INFO-CODE is the least significant 12.

2. He requested the addition of a generic error code for SERVFAIL responses that don't fall into any defined category. For example, it's possible to configure Knot to send SERVFAIL as a result of a policy decision, which doesn't fall into any of the existing buckets, and it would seem silly to add a specific bucket for that.

3. Finally, he recommended removal of the suggestion in section 3.2 that multiple EDE records could be included with a response, and instead forbid it. It makes parsing harder, and it's unclear what to do if different codes contradict one another.

4. Incidental point that I noticed while checking the existing text: "The authors wish to thank...Evan
   Hunt" looks weird if I'm one of authors...

[each]

Pushed some more changes based on Shane's feedback on the mailing list:

• Fixed some inconsistent capitalization.
• Reordered and regrouped the sections to (hopefully) fix the numbering.
• Clean up the list of codes, which had some missing and incorrect codes.

Comments from Shane that are not yet addressed:

Finally, I note that the suggestion of requiring that the sender have some
signal indicating that it is interested in extended errors was not adopted. I
don't insist on it, but I think it would be useful to avoid bloating packets
unnecessarily. It's a bit like the useless additional section data that lots
of servers insist on appending to answers... why send something that will not
be seen?

OTOH I realize that having this information available may be useful for humans
debugging things, even if the sender does not ask for it.

On the gripping hand, adding unasked-for information may have privacy
implications. Possibly adding a "Privacy Considerations" section would be
useful?