Subject: [DNSOP] Éric Vyncke's Discuss on draft-ietf-dnsop-extended-error-14: (with DISCUSS and COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 22 Apr 2020 00:10:20 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-dnsop-extended-error-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document. The document is clear, easy to read and quite useful.

I have a trivial to fix DISCUSS about BCP14 (see below).

I hope that this helps to improve the document,

Finally, I loved reading the acknowledgements section ;-)

Regards,

-éric

-- Section 1.1 --
Trivial to fix: please use BCP 14 boilerplate (see RFC 8174).

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please find below some non-blocking COMMENTs. An answer will be appreciated.

I hope that this helps to improve the document,

Finally, I loved reading the acknowledgements section ;-)

Regards,

-éric

== COMMENTS ==
-- Section 2 --
For my own curiosity, why is there no added semantic in the INFO-CODE ? Such as
a bit or a range for transient errors vs. permanent errors.

It is also a little unclear whether the EDE can happen multiple times (or is it
implicit for EDNS0 option?)

-- Section 4.5 --
The "forged answer" is not qualified in the name but well in the definition
examples. Suggest to rename it in "forged answer by policy" and also create
another code for "forged answer for technical reason" (e.g., DNS64).

We could also wonder whether this code is an "error" code or a "warning" code.
If the latter, then the "EDE" acronym does not really apply anymore (but this
is cosmetic).