Last Call Review of draft-ietf-marf-authfailure-report-
review-ietf-marf-authfailure-report-genart-lc-melnikov-2012-01-01-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-marf-authfailure-report-genart-lc-melnikov-2012-01-01

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