Subject: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-15.txt

From: [email-masked]
Date: Fri, 24 Apr 2020 11:22:35 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Extended DNS Errors
        Authors         : Warren Kumari
                          Evan Hunt
                          Roy Arends
                          Wes Hardaker
                          David C Lawrence
	Filename        : draft-ietf-dnsop-extended-error-15.txt
	Pages           : 14
	Date            : 2020-04-24

Abstract:
   This document defines an extensible method to return additional
   information about the cause of DNS errors.  Though created primarily
   to extend SERVFAIL to provide additional information about the cause
   of DNS and DNSSEC failures, the Extended DNS Errors option defined in
   this document allows all response types to contain extended error
   information.  Extended DNS Error information does not change the
   processing of RCODEs.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-15
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-extended-error-15

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Eric Orth <[email-masked]>
Date: Fri, 24 Apr 2020 15:15:27 -0400

Some comments...

Section 3:

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

Addition of "because" has created a sentence fragment.  Was the intent to
combine these two sentences with a comma?

Section 6:

"As such, EDE content should be treated only as diagnostic information and
MUST NOT alter DNS protocol processing."

(Sorry for not getting back and responding further on this subject in the
previous thread.)

I still object to the ambiguousness of "alter DNS protocol processing"
within a MUST NOT imperative.  Given that the context here is the security
section and a paragraph on EDE generally being untrusted, how about the
statement be scoped down to "alter DNS protocol processing in ways to place
trust in the authenticity of the EDE" or something like that? And maybe,
since the EDE might be trustworthy in some special cases, eg DoH directly
to a special-purpose known-trustworthy resolver, that MUST NOT should be
toned down to SHOULD NOT?

On Fri, Apr 24, 2020 at 2:23 PM <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>