The draft describes a mechanism for reporting the results of applying DMARC policy on mail received at one or more domains.

While reading the document, it was rather difficult to follow because fields are mentioned in the text by identifier'p', 'sp' but the only indication of what the identifier stands for comes in a comment in the schema. All fields and their purpose should be explicitly addressed either in the text itself or by reference to another source.

Given that this specification is describing an infrastructure whose entire purpose is resisting hostile attack, the Privacy Considerations have direct effect on Security and there should be at least a mention of them in the Security Considerations section which should be a 'one stop' shop for all things security.

It probably makes best sense to do the incorporation by reference of this and draft-ietf-dmarc-dmarcbis in the first paragraph of the SC.

The current SC section has bullet points that look like they are placeholders. It would probably help to separate out the concerns according to CIA, 

Some of the confidentiality concerns are covered in the privacy section but there should be consideration of the possibility that revealing which emails were rejected would assist a spammer. For instance, it would be a really bad idea to tell senders how much of their messages are getting through filtering. While the current spec doesn't seem to address that right now, it doesn't warn people not to extend it to do that later.

On the integrity side, there might be some leverage for an attacker in filing bogus reports if their objective was to cause the sender to change their outbound email configuration in some fashion. For example, to purchase an expensive mail delivery reliability product.

On the availability side, automating response to receipt of the reports could well allow a service attack besides the resource exhaustion attacks described. This is alluded to in the second bullet but this is not called out as a service/availability issue.