[DNSOP] Review of draft-ietf-dnsop-no-response-issue-13

[Matthew Pounsett <[e-mail]>]

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.