Skip to main content

Last Call Review of draft-ietf-extra-sieve-action-registry-04
review-ietf-extra-sieve-action-registry-04-secdir-lc-eastlake-2022-11-20-00

Request Review of draft-ietf-extra-sieve-action-registry
Requested revision No specific revision (document currently at 06)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2022-11-23
Requested 2022-11-02
Authors Alexey Melnikov , Kenneth Murchison
I-D last updated 2023-06-27 (Latest revision 2023-03-27)
Completed reviews Genart IETF Last Call review of -04 by Joel M. Halpern (diff)
Secdir IETF Last Call review of -04 by Donald E. Eastlake 3rd (diff)
Artart IETF Last Call review of -05 by Yoshiro Yoneya (diff)
Assignment Reviewer Donald E. Eastlake 3rd
State Completed
Request IETF Last Call review on draft-ietf-extra-sieve-action-registry by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/uaJxxPbySrqqN8YlqiRalHFSCgc
Reviewed revision 04 (document currently at 06)
Result Has issues
Completed 2022-11-20
review-ietf-extra-sieve-action-registry-04-secdir-lc-eastlake-2022-11-20-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  Document
editors and WG chairs should treat these comments just like any other last
call comments.

The summary of the review is Has a Issue.

Sieve Email Filtering Language [RFC5228] is an email filtering language
used upon final mail delivery. This document creates a registry of Sieve
actions in order to help developers and Sieve extension writers track
interactions between different extensions.


*Minor Issues*
Since this document is mostly setting up a tabular IANA Registry, the
Security Considerations do not need to be that extensive. Nevertheless, it
seems likely that there are some security considerations lurking in the
interactions of different actions. If these security considerations are
presented adequately in the many RFCs referenced in the Initial Sieve
Action Registry, then it should be adequate to just add a sentence to the
Security Considerations section something like "For the Security
Considerations of particular actions, see the RFC(s) referenced for that
action in the Initial Sieve Action Registry in Section 2.2." If those RFCs
do not adequately cover it, then more material should be added in this
document.

The one sentence Abstract seems inadequate to me. In my opinion, it needs
more context. At a minimum I suggest copying the first sentence of the
Introduction and make it also be the first sentence of the Abstract. (Since
that sentence has the same RFC reference as the current one sentence
Abstract, one of the two references can be removed from the Abstract.)

*Nits*

See
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-extra-sieve-action-registry-04.txt
(For some reason the nits checker reports that there are many, many entries
in the References sections that are not used in the document. But this
seems to be a problem with the nits checker since a few I checked really
are used in the document.)

The Initial Sieve Action Registry table is too wide by about 24 columns for
there to be a valid .txt version. This might be difficult but here are a
few initial suggestions:
- Decrease the indent for the table by 3 so it is flush left.
- Since none of the entries have anything in the Comments column, eliminate
that column and add text explaining this. (Alternatively, if that is too
radical, you could put the header word "Comments" vertically so it is only
one character wide.)
- Since all the entries in the "Capabilities" column have double quotes
around them, drop the double quotes.
- The entries in the "Cancels Implicit Keep?" and "Can Use with IMAP
Events?" columns are pretty narrow so you could narrow those columns by
narrowing their headers.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com