I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-marf-authfailure-report-07 Reviewer: Alexey Melnikov Review Date: 2012–01–01 IETF LC End Date: 2012-01-04 IESG Telechat date: 2012-01-19 Summary: This draft is almost ready for publication as a standard RFC, but it has some issues that need fixing/discussing. Major issues: I understand that this is a bit pedantic, but ID-nits reports the following: ** Downref: Normative reference to an Experimental RFC: RFC 4408 (ref. 'SPF') and this was not called out during the IETF LC announcement. This reference is truly Normative, so just making it Informative wouldn't work. Minor issues: 1. Introduction [ARF] defines a message format for sending reports of abuse in the messaging infrastructure, with an eye towards automating both the generation and consumption of those reports. There is now also a desire to extend the ARF format to include reporting of messages that fail to authenticate using known authentication methods, as these are sometimes evidence of abuse that can be detected and reported through automated means. The same mechanism can be used to convey forensic information about the specific reason the authentication method failed. Thus, this memo presents such extensions to the Abuse Reporting Format to allow for detailed reporting of message authentication method failures. Maybe that is just me, but when I read "message authentication" I don't really have a clue what you are talking about. I needed to read the rest of the document in order to understand its scope. 2.2. Base 64 base64 is defined in [MIME]. The values that are base64 encodings may contain FWS for formatting purposes as per the usual header field wrapping defined in [MAIL]. During decoding, any characters not in the base64 alphabet are ignored so that such line wrapping does not harm the value. This sentence can be read as allowing other invalid characters outside of FWS. I suggest you reword to make it clear that that is not the case. The ABNF token "FWS" is defined in [DKIM]. 3.1. New ARF Feedback Type: 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. See [I-D.IETF-MARF-REDACTION] for a This reference is currently Normative and is a DownRef (as it wasn't called out explicitly during IETF LC). I don't think the reference needs to be Normative: making it Informative will also get rid of the DownRef problem. discussion of this. 3.2.2. Optional For All Reports Delivery-Result: The final message disposition that was enacted by the ADMD generating the report and MUST NOT appear more than once. The first use of acronym ADMD needs expansion and, ideally, an informative reference to where the term is defined. Possible values are: In Section 4: spf-dns = "SPF-DNS:" : { "txt" / "spf" } [FWS] ":" [FWS] domain [FWS] ":" [FWS] quoted-string I think this field is missing CRLF at the end. Also, other fields listed in the same sections are using CFWS, but this one doesn't. Should ABNF for this be aligned with other fields? Nits/editorial comments: None