[DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Wed, 12 September 2018 20:15 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, draft-ietf-dnsop-refuse-any@ietf.org, dnsop@ietf.org, dnsop-chairs@ietf.org, tjw.ietf@gmail.com
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153678332662.9488.1161578958244899377.idtracker@ietfa.amsl.com>
Date: Wed, 12 Sep 2018 13:15:26 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2cQ5VrHwKNYpQ7MR98Y80Y5fQCM>
Subject: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

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] Eric Rescorla's No Objection on draft-iet… Eric Rescorla
Re: [DNSOP] Eric Rescorla's No Objection on draft… Ólafur Guðmundsson