On Thu, Sep 13, 2018 at 7:15 AM, Eric Rescorla <[email protected]> wrote:
> 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. > > Noted, > > 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? > > The difference is this approach will frequently return more and larger answers than 4.1 but you are right 4.3 is an expansion of 4.1 > 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" > > > Sounds good thanks -- Ólafur Gudmundsson | Engineering Director www.cloudflare.com blog.cloudflare.com
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
