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

From: [email-masked]
Date: Fri, 09 Aug 2019 22:36:54 -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-08.txt
	Pages           : 13
	Date            : 2019-08-09

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.

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-08
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-08

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

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: Wes Hardaker <[email-masked]>
Date: Sat, 10 Aug 2019 11:57:56 -0700

> This draft is a work item of the Domain Name System Operations WG of

A quick update on the draft status and what big changes are published in -08:

1) We removed the rcode binding/copying, after good discussion with
implementation issues at IETF105.  This turned out to be tricky to
implement, since in many cases the EDE information is generated before
an RCODE is actually known.  So the draft is now just a list of un-bound
info codes.

2) The R bit is similarily dropped, due to (un)popular demand.  There
was a lot of discussion about its usefulness, especially being
unauthenticated, and it was clear most (all?) implementations were not
going to look at it.  So out it goes.

The result of #1 and #2 is a very clean packet now, which should be
simple to implement and parse :-)

3) As to the draft status, we went back and processed all comments up
until yesterday and the draft reflects current consensus as we know it.
[we recognize there are comments today that we haven't read yet].  It
has *not* been picked for all possible nits, and needs a complete pass
at this point.  Feel free to give us high level concept suggestions
about the re architecture of everything, or if you're really bored you
could give us grammatical recommendations too, but there will be a lot
and it might be wiser to just wait till we take a pass and push a -09. 

4) Now that this has had multiple implementations (though they'll need
to change after the packet format and code changes [that they
requested]), this is likely ready for last call after passing through
the document for nits and addressing any last comments raised.  We'll
communicate with the chairs about the timing of a LC.

-- 
Wes Hardaker
USC/ISI

---

From: Shane Kerr <[email-masked]>
Date: Mon, 26 Aug 2019 22:17:05 +0200

Wes,

Thanks for the continued work on this draft!

> an RCODE is actually known.  So the draft is now just a list of un-bound

While I thought the RCODE linkage was a bit clunky, the idea of having 
some structure to the response codes was actually kind of nice, for the 
same reason that the 1xx, 2xx, 3xx, 4xx, 5xx status codes were nice. I 
think the draft is better without using RCODE, but maybe we can pick 
numbers for EDE that are grouped in a similar way?

Cheers,

--
Shane

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 30 Aug 2019 16:27:50 -0700

Shane Kerr <[email-masked]> writes:

> some structure to the response codes was actually kind of nice, for
> the same reason that the 1xx, 2xx, 3xx, 4xx, 5xx status codes were
> nice. I think the draft is better without using RCODE, but maybe we
> can pick numbers for EDE that are grouped in a similar way?

So, assuming we *can't* easily group them by rcode.  Well, we can, but
the results may not match given discussions with implementers.

If you want to take a whack at suggesting appropriate ranges I'd love to
see what you come up with.  As with all loaves of bread, do you slice
them cross-wise, length-wise or diagonally?

[I reminded my daughter the other day that when she was young I made
her sandwich in the morning for school and cut it in half using a
lightning bolt like cut because she was a fan of Harry Potter]
-- 
Wes Hardaker
USC/ISI