Domain-based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting
draft-ietf-dmarc-failure-reporting-25

Thanks to Christian Huitema for their multiple secdir reviews. 

Section 7.3:  I agree with Mike Bishop - either define or replace the word 'defang'.  A non native English speaker might be confused. It could easily be replaced with 'URIs can be made harmless by substituting' or similar.

# 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.
+                                            ^                 ^^^
```

Hi Steven & Alessandro,

Thanks for the effort put into this specification. Also, congrats to the WG for submit document to the IESG no later than six months from working group formation per the charter ;-)

Other than the abstract should mention both updated and obsoleted RFCs, I have only very few nits that I will sent in a PR for authors convenience.

Cheers,
Med

Thank you to Ines Robles for the GENART review.