Re: [Last-Call] [secdir] SECDIR Review of draft-ietf-extra-sieve-action-registry-04

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Alexey,

I am satisfied with your resolution of my comments.

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


On Mon, Dec 5, 2022 at 9:57 AM Alexey Melnikov <alexey.melnikov@xxxxxxxxx> wrote:

Hi Donald,

Thank you for your review.

On 21/11/2022 03:17, Donald Eastlake wrote:
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."
Existing RFCs should cover interactions. I will add your suggested sentence.
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.)
Ok.

Nits

See
https://author-tools.ietf.org/api/idnits?url="">
(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.

I would like to mostly leave this to RFC Editor to figure out formatting of the table, but I like the idea of dropping the "Comments" column.

Best Regards,

Alexey


-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux