Authentication Failure Reporting Using the Abuse Reporting Format
draft-ietf-marf-authfailure-report-10

I have no objection to the publicaiton of this document as an RFC, but
here are a few trivial nits.

---

Please expand "AF" on first use in the Abstract, and show it as the
abbreviation of "Abuse Report Format" on first use in the Introduction.

---

Section 3.1

   Delivery-Result:  As specified in Section 3.2.2.  This field is
      OPTIONAL, but MUST NOT appear more than once.  If present, it
      SHOULD indicate the outcome of the message in some meaningful way,
      but might be redacted to "other" for local policy reasons.

s/might/MAY/

---

Section 3.2.2

Please expand ADMD

---

Section 3.2.3

Please expand DKIM

---

Section 3.2.5

Please expand ADSP

---

Section 3.2.6

Please expand SPF

Section 2.3 states:

   base64 is defined in [MIME].

Well, base64 is also defined in RFC 4648. :) Perhaps it would be better to say:

   This specification mandates use of base64 as defined in [MIME].

Section 3.1 states:

   Delivery-Result:  As specified in Section 3.2.2.  This field is
      OPTIONAL, but MUST NOT appear more than once.  If present, it
      SHOULD indicate the outcome of the message in some meaningful way,
      but MAY be redacted to "other" for local policy reasons.

I think "redacted" is not right here (causes confusion with the redaction I-D). I suggest "set".

Section 3.1 also states:

   For privacy reasons, report generators might need to redact portions
   of a reported message such as the end user whose complaint action
   resulted in the report.  A discussion of relevant issues and a
   suggested method for doing so can be found in
   [I-D.IETF-MARF-REDACTION].

I don't think you can redact an end user. :) I suggest "an identifier or address associated with the end user..."

Section 6.2 states: "These reports may be forged" and "DKIM failure reports may produce reports". I suggest changing "may" to "can" and "might", respectively.

Section 6.3 states:

   Limiting the rate of generation of these messages may be appropriate
   but threatens to inhibit the distribution of important and possibly
   time-sensitive information.

Do you mean "MAY"?

Section 6.5 states:

   The use of this for "near-identical" incidents in particular causes a
   degradation in reporting quality, however.  If for example a large
   number of pieces of spam arrive from one attacker, a reporting agent
   may decide only to send a report about a fraction of those messages.
   While this averts a flood of reports to a system administrator, the
   precise details of each incident are similarly not sent.

Do you mean "MAY"?

I find it a little odd that the requirements language for what's optional/required in the different reports (s3.2.*) appear in the section titles but not in the text.

- Section 2.4 (esp the title) is a bit odd, I'm sure its
there for a reason but its not at all clear to this reader.
(But I don't mind)

- 3.1 - who's SOURCE-IP is meant here? Might be clear from
ARP but not so clear from here - same for REPORTED-DOMAIN.
Better to be crystal clear really.

- 3.2.1 - the "policy" value is a bit vague, but that's ok
I guess.

- I'm not 100% clear about the rule for handling DKIM and
redaction. Is it that the sender just chooses whether to
send the unredacted possibly-DKIM-valid value or the
redacted version with no DKIM info, or are you just supposed
to never (as in MUST NOT) send a redacted message if the
message had DKIM header fields? That might be there but I
missed it if so.