[Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-fetch-preview-03: (with COMMENT)
Benjamin Kaduk via Datatracker <firstname.lastname@example.org> Wed, 10 April 2019 13:34 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DB71200D7; Wed, 10 Apr 2019 06:34:28 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Benjamin Kaduk via Datatracker <email@example.com>
To: "The IESG" <firstname.lastname@example.org>
Cc: email@example.com, Bron Gondwana <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com
Reply-To: Benjamin Kaduk <firstname.lastname@example.org>
Date: Wed, 10 Apr 2019 06:34:28 -0700
Subject: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-fetch-preview-03: (with COMMENT)
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2019 13:34:28 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-extra-imap-fetch-preview-03: 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-extra-imap-fetch-preview/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [Re-issuing ballot position to direct discussion of the ABNF for 'capability' to Barry's ballot thread; the rest of the COMMENT is unchanged] Section 3.1 Alternately, the client may explicitly indicate which algorithm(s) should be used in a parenthesized list after the PREVIEW attribute containing the name of the algorithm. These algorithms MUST be one nit: there's potential for misparsing here (e.g., that the PREVIEW attribute contains the name of the algorithm and the parenthesized list is after that), so maybe put "after the PREVIEW attribte" in parentheses or offset by commas. of the algorithms identified as supported in the PREVIEW capability responses. [...] nit: singular/plural mismatch between "these algorithms" and "one of". Section 7 How much discussion was there about "SHOULD be registered" (as opposed to "MUST be registered")? Section 8 side note: This is one of the shortest IANA considerations sections I've seen thta creates registries (in that it doesn't lay out a registration template), but IANA seems to be saying they have what information they need, so who am I to complain... Section 9 I agree with Roman that there should be discussion of the caching/data retention strategy for message previews. This existing text about denial-of-service attacks is probably fine, though I might consider rephrasing it along the lines of "this mechanism introduces a new way for clients to make requests that consume server resources. As is the case for all such mechanisms, it could be used as part of a denial-of-service attack on server resources, e.g., via excessive memory or CPU usage, or increased storage if preview results are cached on the server after generation. The additional attack surface presented by this specific mechanism is not believed to higher risk that other similar mechanisms in use already, since the individual resource consumption per message processed is likely to be modest. Nonetheless, servers MAY limit the resources consumed by preview generation." As I write the above, though, I wonder how this interacts with the previous text in Section 3.1 about how the "server MUST honor a client's algorithm priority decision". Does that mean that if some future (expensive) algorithm is specified, once a server implements that algorithm, any client can force its use and thus the expensive resource consumption on the server? It's not entirely clear to me how this MAY interacts with that MUST, in such a hypothetical scenario.
- [Extra] Benjamin Kaduk's No Objection on draft-ie… Benjamin Kaduk via Datatracker