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

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:

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