[Gen-art] Gen-ART review: draft-ietf-marf-as-13

Martin Thomson <martin.thomson@gmail.com> Fri, 13 April 2012 16:13 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2A37821F8618 for <gen-art@ietfa.amsl.com>; Fri, 13 Apr 2012 09:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.949
X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id dd4PPNpDBsVp for <gen-art@ietfa.amsl.com>; Fri, 13 Apr 2012 09:13:58 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 30E7121F8603 for <gen-art@ietf.org>; Fri, 13 Apr 2012 09:13:58 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so3089643bku.31 for <gen-art@ietf.org>; Fri, 13 Apr 2012 09:13:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=dXfIUspZXN6JNaaujNBqmmNcOGxiPwP44TDJ7u5zEk0=; b=jrnLZWzQtByp4QPJ7PgibJG02C8YCHxWZlhqSPy3FQnXFGABjuMAHOTra8XsxHB4xA pVEqFzCIr1B2C0R4kR/FAdiMHAQUM3cEJqPKcHAnrsJ0FH6ggt+WMh+A2zVd5a4ZvO/s kdy08YdNXkq5PLJLT8ZnUPxoEWId0LYelDwSoaknjFopXsf4F1027O/HQxvUaUbvQ/Pc SMsfs/h6eg7XaeOCR7acfD838mWR5rVI8lJm23wM5kPWtkT2Uwwt0VVfLFLJ0EIECg9U 6+2GI7mQqVVD3wKXR+5z9fLPup2r0PzpbJiBddlREMn2esT/xMNY7qLHbjRPwD7A12E8 UU8Q==
MIME-Version: 1.0
Received: by with SMTP id m28mr625580bkw.102.1334333637241; Fri, 13 Apr 2012 09:13:57 -0700 (PDT)
Received: by with HTTP; Fri, 13 Apr 2012 09:13:57 -0700 (PDT)
Date: Fri, 13 Apr 2012 09:13:57 -0700
Message-ID: <CABkgnnXEnqmOcszw4KcXOcs_Z-C+zwhtC2tpdr73YQqjQmX3ZQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: draft-ietf-marf-as.all@tools.ietf.org
Content-Type: text/plain; charset=UTF-8
Cc: gen-art@ietf.org
Subject: [Gen-art] Gen-ART review: draft-ietf-marf-as-13
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 16:13:59 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-marf-as-13
Reviewer: Martin Thomson
Review Date: 2012-04-12
IETF LC End Date:
IESG Telechat date: (if known)

Summary: This document is fit for publication, though some minor
issues might warrant further consideration.

Major issues: None

Minor issues:

Reading through, this doesn't smell very much like an applicability
statement at all.  It has the distinct odor of a profile, or a set of
implementation/deployment/operational guidelines.  That might just be

Section 4.2 doesn't really contain enough information for me to
determine when I might want to ignore your SHOULD.

Section 6.1, point 1 cannot be an interoperability requirement if
there isn't a mechanism provided.  The text is perfectly clear, but I
can't implement anything here to address the "MUST".  The problem is
that the reports are unsolicited, and therefore an out-of-band
"session" has not been established between providers. (Is an abuse
report the in-band solution you are looking for?  Yes, Section 7,
point 2, I know...)

Section 6.3, point 1 has the same complaint for the "SHOULD", though
in this case the softness of the "SHOULD" makes this more tolerable.

Nits/editorial comments:

Expand on first use: MUA, SPF, DKIM.

Parentheses around references is excessive ([CITE]).

Section 5.2, point 2 is a bit of a truism...MUST support optional
fields being optional.  Is it really necessary?

Section 6.3, point 3, sentence 2: missing comma after "([RFC3912])"

Section 6.4, point 3, did not parse: "reports are generated with use
by recipients not using"

Section 6.5, point 3 could be made MUST NOT by saying "MUST NOT reject
non-ARF messages based solely on the format" or by adding other
qualifications to that effect.  Obviously this has to allow for local
policy that rejects messages on other criteria, but you can make a
requirement like this.