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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
