On 31. 08. 19 1:27, Wes Hardaker wrote: > Shane Kerr <[email protected]> writes: > >> 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? > > 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?
Main question is not "what categories we need" but "what is the purpose/who is consumer of the information"? Once we have answer to this it will be easier to establish a categorization. IMHO the most useful information is dichotomy: a) the problem is local (= call network admin/ISP/telco) b) the problem is remote (= call your bank because their internetbanking broke and _do not your bother ISP_). Such simple distinction would allow client apps way more informative message than "We’re having trouble finding that site" + would make life easier for support people. This distinction is especially important for DNSSEC validation failures - e.g. if RRSIGs are expired your ISP/resolver operator _should not_ take any action so it is desirable to "assign blame" to web site owner. Shane, what do you think about proposal at the end of message https://mailarchive.ietf.org/arch/msg/dnsop/JHYQunp0L7C_vUcBb9fOi22QfpI - specifically Near and Far bits? Also we need to ask stub resolver developers what would be useful for them. Bernardo, what information would make life easier for stub/app developers? -- Petr Špaček @ CZ.NIC _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
