Subject: [Gen-art] Gen-ART last call review of draft-ietf-marf-authfailure-report-07

From: Alexey Melnikov <[email-masked]>
Date: Sun, 01 Jan 2012 20:30:08 +0000

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 1 Jan 2012 12:57:28 -0800

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Sunday, January 01, 2012 12:30 PM
> To: Hilda L. Fontana; Murray S. Kucherawy; Pete Resnick
> Cc: [email-masked]; The IESG
> Subject: Gen-ART last call review of draft-ietf-marf-authfailure-
> report-07

Hi Alexey,

> This reference is truly Normative, so just making it Informative

Yep, this was pointed out by someone else too.  I missed it during my shepherd write-up.  It's been moved to the 1/19 telechat, partly because we'll probably need a second LC to handle this properly.

> 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.
> 
> really have a clue what you are talking about. I needed to read the
> rest of the document in order to understand its scope.

Rather than adding a paragraph or two about what message authentication is, would it be sufficient to add references to the SPF and DKIM specifications, and perhaps the DKIM Threats document, to the second sentence above (a la "such as...")?  I'm weary of adding text that repeats what's stated elsewhere and would prefer we just add some references to appropriate reading.

> During decoding, any characters not in the base64 alphabet are ignored
> so that such line wrapping does not harm the value.
> 

Easy; will do.

> token "FWS" is defined in [DKIM].

Right.

> will also get rid of the DownRef problem.

The Working Group is considering doing either that or upgrading the redaction draft to Proposed Standard.  Both of those approaches would deal with it nicely.  We'll have figured that out by the time of the 1/19 telechat.

> informative reference to where the term is defined.

That's RFC5598.  Will do.

> but this one doesn't. Should ABNF for this be aligned with other

Yes to both.  Also an easy fix.

Thanks!  We'll get a new one posted as soon as the WG decides the document status question.

-MSK

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 01 Jan 2012 21:08:55 +0000

>> Subject: Gen-ART last call review of draft-ietf-marf-authfailure-
Hi Murray,
> Yep, this was pointed out by someone else too.  I missed it during my shepherd write-up.  It's been moved to the 1/19 telechat, partly because we'll probably need a second LC to handle this properl…
Yep.
> Rather than adding a paragraph or two about what message authentication is, would it be sufficient to add references to the SPF and DKIM specifications, and perhaps the DKIM Threats document, to the second sentence above (a la "such as...")?
That would be fine.
(I originally was asking myself if TLS and SASL authentication was in 
scope, but it is clearly isn't.)
> I'm weary of adding text that repeats what's stated elsewhere and would prefer we just add some references to appropriate reading.
>
>> 2.2. Base 64
>>
I forgot to mention: It might be worth referencing the base64 RFC instead.

  [...]