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

"Murray S. Kucherawy" <> Fri, 13 April 2012 19:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17CF921F87A2 for <>; Fri, 13 Apr 2012 12:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.542
X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0zIsWXf1ZoM5 for <>; Fri, 13 Apr 2012 12:14:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3D41C21F877B for <>; Fri, 13 Apr 2012 12:14:25 -0700 (PDT)
Received: from ([]) by with bizsmtp id xXEJ1i0020ZaKgw01XEJjn; Fri, 13 Apr 2012 12:14:24 -0700
X-CMAE-Match: 0
X-CMAE-Score: 0.00
X-CMAE-Analysis: v=2.0 cv=H85ZMpki c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=7kMX6eKFbxAA:10 a=zutiEJmiVI4A:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=aBl6_qVZLh-e_HCwMi4A:9 a=88_gob-PgkVewUbxR-kA:7 a=QEXdDO2ut3YA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=QQTW8CIwiUlVY4Xl:21 a=HANvhiNlQJPq0I6t:21 a=LdFkGDrDWH2mcjCZERnC4w==:117
Received: from ([fe80::addf:849a:f71c:4a82]) by ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Fri, 13 Apr 2012 12:14:18 -0700
From: "Murray S. Kucherawy" <>
To: Martin Thomson <>, "" <>, "" <>
Thread-Topic: Gen-ART review: draft-ietf-marf-as-13
Thread-Index: AQHNGZB+7c4QMrJmK06xaah5486YRZaZGYxA
Date: Fri, 13 Apr 2012 19:14:17 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1334344464; bh=ixXgRY7oSk6nqmOc1NHXp241tkmZCEZH7zkWbnSSGFw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=lNWQNy7EQwJ1jwDo1SIAoo850XX1HyhgijlqEvax5e0S2LGQ/qbr/F88LqM4ATli3 EfzT7cOPlefklMD0UM7Tz5UvzlhVAqxxNySI9hhaiKLVEZ1UPGCuvtkJVEZRWieWu3 oTtkOVhnP0ZCGFyWYavahNA3GWg2Mn/C3WOhReT8=
Cc: "" <>
Subject: Re: [Gen-art] Gen-ART review: draft-ietf-marf-as-13
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Apr 2012 19:14:26 -0000

> -----Original Message-----
> From: Martin Thomson []
> Sent: Friday, April 13, 2012 9:14 AM
> To:
> Cc:
> Subject: Gen-ART review: draft-ietf-marf-as-13

Hi Martin, thanks for the review.

> 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
> me.

It is an Applicability Statement in the sense of Section 3.2 of RFC 2026.

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

Some kind of out-of-band knowledge of an override address, or local policy, is what we have in mind here.  Of course, such out-of-band knowledge is likely an implicit part of the feedback solicitation agreement anyway, so really local policy is the only thing that might apply.  We can mention that explicitly.

> 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...)

Existing implementations generally support this capability, but they all have different ways of doing so.  Thus, there's (currently) no standard way to do it.  Our ADs thus suggested the text that's there.

> 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.

The choice to deviate means the benefits described later in that point's text are lost.  That's the tradeoff.

> Nits/editorial comments:
> Expand on first use: MUA, SPF, DKIM.


> Parentheses around references is excessive ([CITE]).

Stylistic preference, I think.  :-)

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

Hm, true.  I'll have to look at how that text evolved and figure out if it needs rewording or can just be dropped.

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

Why?  It doesn't parse properly with that change.

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

"with ... in mind" is the construct, but they are kind of far apart.  Will reword.

> 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.

I think a mix of the two makes sense: Leave it a SHOULD NOT, use your wording otherwise, and then describe valid deviation criteria as you've done.

Thanks; LC ends 4/24, will post a revision between that and the telechat.