Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

["Paul Hoffman" <[e-mail]>]

The draft seems almost ready to go to the IETF. However, there are still 
a few areas that need work.

As others have discussed, the filename really has to change. Like it or 
not, RFCs get associated with the last draft name that produced it, and 
"refuse-any" is just wrong for this document.

The current title, "Providing Minimal-Sized Responses to DNS Queries 
with QTYPE=ANY", makes sense to DNS experts but probably not to anyone 
else. Proposed change: "Providing Minimal-Sized Responses to DNS Queries 
That Have a Query Type of 'ANY'". It's longer, but it will make much 
more sense to others.

The organization of the document makes it hard for an implementor to 
decide which text is about the first option (send back one or a subset 
of real RRs), which is about the second option (send back a synthesized 
HINFO), and which refers to both. This can be alleviated by reorganizing 
the existing text.
   - Move "This proposal specifies two different modes of behaviour by 
DNS..." and the two bullet points out of Section 3 and into the top of 
Section 4.
   - Split Section 4 into three subsections: "4.1 Select a Subset", "4.2 
Synthesize an HINFO Record", and "4.3 Topics Relevant to Either 
Deployment Option".
   - Move the text from Section 6 into the new Section 4.2.

On the topic of HINFO versus another RRtype, I think HINFO is fine. The 
fact that some servers use HINFO is a red herring: the answers described 
in this document only are returned for QTYPE=ANY, not for QTYPE=HINFO. 
Having said that, the following text from Section 6 seems wrong: 
"Authority-server operators who serve zones that rely upon conventional 
use of the HINFO RRTYPE MAY sensibly choose not to deploy the mechanism 
described in this document or select another type". A much more logical 
approach would be "Authority-server operators who serve zones that rely 
upon conventional use of the HINFO RRTYPE SHOULD choose to respond with 
a subset of the RRtypes, as described in Section 4.1".

The text "Except as described in this section, the DNS responder MUST 
follow the standard algorithms when constructing a response" is unclear 
unless you call out RFC 1035.

In Section 5, it is not clear why an initiator MAY cache the response. I 
believe it SHOULD cache the response as a normal DNS response.

--Paul Hoffman