Mike Bishop has entered the following ballot position for draft-ietf-dmarc-failure-reporting-23: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-failure-reporting/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # IESG review of draft-ietf-dmarc-failure-reporting-23 CC @MikeBishop ## Comments ### Section 2, paragraph 5 ``` when they will be sent, are defined by the "ruf" and "fo" tags as defined in Section 4.7 of [I-D.ietf-dmarc-dmarcbis]. ``` Consider "provided by" to avoid using "defined by" twice? ### Section 2, paragraph 6 ``` Report generators MUST ensure not to flood report consumers with excessive reports, which would allow denial-of-service, see Section 8.1. ``` Is this precise enough to be a MUST? How would a peer determine if the generator is violating this and how would they respond? I think the normative part is that a generator MUST implement a rate-limit, and we recommend (non-2119) that it be set to some reasonable value. ### Section 5.1, paragraph 2 ``` Reporters MAY rate limit the number of failure reports sent to any ``` Why MAY here, when it's MUST above? ### Section 7.3, paragraph 3 ``` * defang URIs by substituting hxxp for http; ``` Is "defang" a defined term anywhere? If not, I'd consider spelling out what you mean by this, presumably "Help prevent accidental access to potentially-malicious URIs by..." ### Section 7.3, paragraph 2 ``` * remove malicious attachments such as word documents or pdfs. ``` These examples may be overly specific; perhaps instead "attachments which could embed malicious payload"? ### Missing references No reference entries found for these items, which were mentioned in the text: `[CFWS]`, `[RFC5322]`. ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 2, paragraph 7 ``` - excessive reports, which would allow denial-of-service, see - ^ + excessive reports, which would allow denial-of-service; see + ^ ``` #### Section 5.1, paragraph 1 ``` - Email streams carrying DMARC failure reports SHOULD be DMARC aligned. - ^ + Email streams carrying DMARC failure reports SHOULD be DMARC-aligned. + ^ ``` #### Section 7.3, paragraph 3 ``` - * remove malicious attachments such as word documents or pdfs. - ^ ^^^ + * remove malicious attachments such as Word documents or PDFs. + ^ ^^^ ``` _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
