refuse-any
(1) This documet is being presented as a Proposed Standard. It is
stated in the title page and it is the proper type of RFC.
(2)
Technical Summary:
The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
The operator of an authoritative DNS server might choose not to
respond to such queries for reasons of local policy, motivated by
security, performance or other reasons. This document provides
specific behaviorial guidance for DNS servers and/or clients.
Working Group Summary
There was some initial issues reaching consensus during WGLC, but
the authors worked out the specific issues with the working group
and the final version met with strong consensus.
Document Quality
Document has been well written and edited. There are current
implementaions that help drive consensus.
Personnel
Document Shepherd is Tim Wicinski and Area Director is Warren
Kumari.
(3) The document shepherd did several thorough reviews of this
document, both for content as well as editing issues.
(4) The document shepherd is more than satisfied with the depth and
breath of the reviews.
(5) It is the opinion of the document shepherd that this document does
not need broader reviews.
(6) The document shepherd has no specific concerns or issues with this
document.
(7) The authors have confirmed that there are no IPR disclosures that
need to be filed.
(8) No IPR disclosures have been filed for this document.
(9) WG Consensus is solid.
(10) There has been no threats to appeal or discontent.
(11)
-- The draft header indicates that this document updates RFC1034,
but the abstract doesn't seem to mention this, which it should.
-- The draft header indicates that this document updates RFC1035,
but the abstract doesn't seem to mention this, which it should.
Found 'SHOULD not' in this paragraph:
It is important to note that returning a subset of available
RRSets when processing an ANY query is legitimate and consistent
with [RFC1035]; it can be argued that ANY does not always mean
ALL, as used in section 3.2.3 of [RFC1035]. The main difference
here is that the TC bit SHOULD not be set on the response
indicating that this is not a complete answer.
(12) Document does not meet any required formal review criteria.
(13) All references have been identified as either normative or
informative.
(14) There are not normative references that are holding up this
document.
(15) There are no downward normative references in this document.
(16) This document will update RFC 1034 and RFC 1035. These RFCs are
listed int the title page, discussed in the introduction. These RFCs
are not mentioned in the abstract.
(17) The IANA considerations section requests an update to the Resource
Record (RR) Types Registry to reference this document for one value.
This is consistent with the body of the document.
(18) There are no new IANA registries.