Subject: [DNSOP] extended error changes based on your comments

From: Wes Hardaker <[email-masked]>
Date: Fri, 09 Aug 2019 22:29:05 -0700

Thanks for your feedback about the extended errors draft.  Below are
responses to some of your previously raised points in email to dnsop:

8.5 Evan Hunt
~~~~~~~~~~~~~

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

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

  + Response: A few of us met in IETF105 and agree to drop the
    RESPONSE-CODE.  And yes, network-byte order is critical and has been
    specified in the most recent document.  Thanks!

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

  + We're adding a "other" type error code and agree this is a good
    suggestion.

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

  + The debugging codes shouldn't be used for decision making process,
    and clients must not fail when they receive multiple options anyway.
    It would be better to specify that you better expect it than have
    clients not be able to handle them.  We expect most clients will
    log/display all errors and "contradicting" doesn't make much sense
    from a non-decision making logic tree.

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

  + Response: Ha.  Very true, thanks.  You've been removed!

    (he laughs manically at the thought of Evan wondering "wait.... from
    the acknowledgements or from the author list???")

  ----------------------------------------------------------------------

  You can view, comment on, or merge this pull request online at:

  [https://github.com/wkumari/draft-wkumari-dnsop-extended-error/pull/5]

  Commit Summary

  * address some feedback from the IETF hackathon in Prague
  * remove me from the thank you's, since I'm a coauthor
  * add a "Not Specified" SERVFAIL code

  File Changes

  * M draft-ietf-dnsop-extended-error.xml (41)

  Patch Links:

  * [https://github.com/wkumari/draft-wkumari-dnsop-extended-error/pull/5.patch]
  * [https://github.com/wkumari/draft-wkumari-dnsop-extended-error/pull/5.diff]

-- 
Wes Hardaker
USC/ISI