I promised a new review of this document a long time ago. Apologies for taking so long to get around to it.
This is a huge improvement over previous versions. I'd like to thank the authors for such an extensive cleanup. I sill have a few style suggestions (and grammar nits), which I think would make it a better document, but nothing that should actually block it from proceeding. My only real structural suggestion is that I still find the style of the subsections of section 3 to be odd reading. Some sections only describe a correct behaviour (3.1.3.1), some only describe a common incorrect behaviour (3.1.3), others only describe a test for detecting whether a server behaves correctly or not (3.1.1). Most subsections of 3.x are combinations of two or more of these in apparently random order; some lead with a test, some lead with an incorrect behaviour, some lead with a correct behaviour. Having a more consistent structure to these sections would make the document easier to read and act on. I think tests should be left out of 3.x entirely, and moved to section 8 if they aren't already there. If the authors want to point out tests in this section, a pointer to the relevant subsection of 8.x would be more appropriate. The rest of my comments are smaller style or grammar nits: Section 3 title: "Common queries kinds" I raised this issue in a previous version; this does not seem to be correct English. Do the authors mean "Common kinds of queries"? Section 7, paragraph 2: For unimplemented opcodes NOTIMP is the expected response code. For example, a new opcode could change the message format by extending the header or changing the structure of the records etc. This is not, strictly speaking, an example of what's being talked about in the previous sentence. Suggested text: Newly implemented opcodes may change the message format by extending the header, changing the structure of the records, etc. Servers are not expected to be able to parse these, and should respond with a response code of NOTIMP when they encounter a query with an unknown opcode, rather than dropping the message. Section 8: Most of the second paragraphs of the subsections of 8 are written with the general structure of: We expect A with B and C and D. I find this to be awkward list construction. I think it would be more useful to structure these as: We expect A, B, C, and D. For example, subsection 8.1.2: We expect no records to be returned in the answer section with the rcode set to NOERROR and the AA and QR bits to be set in the response; RA may also be set [RFC1034]. We do not expect an OPT record to be returned [RFC6891]. This could be: We expect no records to be returned in the answer section, the rcode to be set to NOERROR, and the AA or QR bits to be set in the header; RA may also be set [RFC1034]. We do not expect an OPT record to be returned [RFC6891]. I'm happy to provide suggested text for all of these if that's useful to the authors. 8.1.3.1, first paragraph. Too many "and"s, not enough commas. :) Suggested text: Ask for the SOA record of the configured zone. This query is made with only the CD DNS flag bit set, all other DNS bits clear, and without EDNS. 8.2.3, first paragraph: Any unassigned EDNS option code could have be choose for this test. Any unassigned EDNS option code could have been choosen for this test.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
