[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-extended-error-15: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Fri, 24 April 2020 19:51 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-extended-error@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, tjw.ietf@gmail.com
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158775787447.14986.12634580210778900165@ietfa.amsl.com>
Date: Fri, 24 Apr 2020 12:51:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_OsOgfy5vavI2d6qm9wXxVnRIAw>
Subject: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-extended-error-15: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-extended-error-15: No Objection

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/



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

Thank you for addressing my Discuss point!
It's probably worth a second look at the IANA considerations (see below),
and I do have a few other comments.

Section 1

Were you going to say something about EDE allowing stubs to stop after
SERVFAIL-due-to-DNSSEC-bogus instead of continuing on to a non-validating
resolver?

Section 2

(I note that BCP 18 likes a language indicator, and "intended for human consumption"
relies on humans to be language detectors, which is not always reliable.)

Section 3

   the truncation bit when dropping EDE options.  Because long EXTRA-
   TEXT fields may trigger truncation, which is undesirable given the
   supplemental nature of EDE.  Implementers and operators creating EDE
   options SHOULD avoid lengthy EXTRA-TEXT contents.

I think this was intended to be one sentence, not two?

Section 5.2

Are these two snippets consistent with each other?

   o  0 - 49151: First come, first served.
   o  49152 - 65280: Private use.
[...]
   INFO-CODE:  25-65535
   Purpose:  Unasigned
   Reference:  Section 5.2

Section 6

   unauthenticated information.  As such, EDE content should be treated
   only as diagnostic information and MUST NOT alter DNS protocol
   processing.  Until all DNS answers are authenticated via DNSSEC or

This looks an awful lot like the text Eric Orth didn't like when proposed
in the secdir review thread.

[DNSOP] Benjamin Kaduk's No Objection on draft-ie… Benjamin Kaduk via Datatracker