Subject: [DNSOP] Last Call: <draft-ietf-dnsop-extended-error-14.txt> (Extended DNS Errors) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 12 Mar 2020 08:17:57 -0700

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Extended DNS Errors'
  <draft-ietf-dnsop-extended-error-14.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-04-02. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 22 Mar 2020 18:10:31 -0400

Hi,

My apologies for getting in some minor comments so late. I do not suggest
any technical changes. However, at least to my eye, there are some little
glitches and editorial changes I would suggest.

Among the glitches I see are incorrect internal cross references, old
implementation key word boilerplate, no specification for assignment policy
for one range of INFO-CODE values, misspelled words, etc. Editorial changes
are somewhat of a matter of taste. In any case these are also marked in the
attached.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

On Thu, Mar 12, 2020 at 11:18 AM The IESG <[email-masked]> wrote:

> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 30 Mar 2020 13:35:35 -0700

Donald Eastlake <[email-masked]> writes:

> My apologies for getting in some minor comments so late. I do not
> suggest any technical changes.  However, at least to my eye, there are
> some little glitches and editorial changes I would suggest.

Thanks for the detailed review, comments and suggestions Donald.
Responses inline below.  Any thing *not* mentioned below should consider
accepted :-) A few of the editorial changes I left unchanged as well,
since I suspect the RFC Editor will likely make the final call on
whether commas are needed in certain spots when you and I disagree on
whether they're needed or not.

The full diff of changes from applying your changes can be found here:

https://github.com/wkumari/draft-wkumari-dnsop-extended-error/commit/adcd34da305737e57964676cd1376263e8803239

> [deletion of the rfc editor note]

I  left this in, since it easily flags where help is needed.

> (SERVFAIL, NXDOMAIN, REFUSED, -and even- NOERROR, etc)

You removed "and even" but I'm leaving it in, since there was a lot of
discussion around NOERROR and how that seemed odd to people.  The
extract "and even" text helps calls needed attention to it, IMHO.

> "Because long EXTRA-TEXT fields may trigger truncation,
>  which is undesirable given the supplemental nature of
>  EDE."

I left this sentence as a hybrid of what you suggested (removing most of
the second half), leaving in the supplemental component since I believe
that also is a subtle thing that should be called out.  Maybe others
believe your text is better though?

I left in your suggested "on the ... [IANA] web page as follows:", but
I'm not sure that's the right text either.  We want the creation of a
registry, which *happens* to be listed on a web page as well.

I also do not add the "reserved" section since the IANA ranges were
discussed extensively and the current number ranges are the result of a
consensus I didn't want to have one person change without a lot of
backup agreement.

-- 
Wes Hardaker
USC/ISI

---

From: Eric Orth <[email-masked]>
Date: Mon, 30 Mar 2020 19:06:38 -0400

> believe your text is better though?

I think that the "supplemental..." text is important because that makes
clear that this isn't just a boilerplate description of standard DNS
behavior but is actually an important warning specific to subtle
implications of the nature of EDE.

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

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 30 Mar 2020 21:19:51 -0400

Hi Wes,

> whether they're needed or not.

OK. Thanks for accepting so many of my suggestions.

> extract "and even" text helps calls needed attention to it, IMHO.

OK.

> registry, which *happens* to be listed on a web page as well.

Generally, IANA likes quite specific instructions/requests. If IANA
has any problem with the instructions/request, they will let us know.

> consensus I didn't want to have one person change without a lot of

This is the only serious problem I see. The assignment policy/status
will have to be specified for every value. I agree that I should not
be specifying the status of the range that was omitted and for which I
suggested "reserved". Given this gaping hole in the IANA
Considerations, I imagine that the IESG will impose a policy for that
range or, alternatively, the IESG and/or IANA will bounce the draft
back to the WG get this filled in.

Thanks again,
Donald

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 31 Mar 2020 11:33:03 -0700

> back to the WG get this filled in.

We might be mis-communicating...  I did add your "unassigned" tag, just
not the "reserved" one beyond that.  IE, the text now looks like:

   INFO-CODE:  25-65535
   Purpose:  Unasigned
   Reference:  Section 5.2

-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 31 Mar 2020 11:33:41 -0700

Eric Orth <[email-masked]> writes:

> I think that the "supplemental..." text is important because that makes clear that this isn't just a boilerplate
> description of standard DNS behavior but is actually an important warning specific to subtle implications of the
> nature of EDE.

Thanks for the feedback Eric.
-- 
Wes Hardaker
USC/ISI