Eric Rescorla has entered the following ballot position for draft-ietf-dnsop-refuse-any-07: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D5482 COMMENTS S 3. > processing in order to send a conventional ANY response, and avoiding > that processing expense might be desirable. > > 3. General Approach > > This proposal provides a mechanism for an authority server to signal Nit: authoritative. S 4.3. > applications may be satisfied by this behaviour, the resulting > responses in the general case are larger than the approaches > described in Section 4.1 and Section 4.2. > > As before, if the zone is signed and the DO bit is set on the > corresponding query, an RRSIG RRSet MUST be included in the response. This section seems to be one possible algorithm for implementing 4.1. What am I missing? S 7. > 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. This is a bit grammatically awkward, perhaps "response, thus indicating" _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
