Re: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back

"Murray S. Kucherawy" <msk@cloudmark.com> Tue, 14 February 2012 20:41 UTC

Return-Path: <msk@cloudmark.com>
X-Original-To: marf@ietfa.amsl.com
Delivered-To: marf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C494E21E80C9 for <marf@ietfa.amsl.com>; Tue, 14 Feb 2012 12:41:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.594
X-Spam-Level:
X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nI0gw9WHECRj for <marf@ietfa.amsl.com>; Tue, 14 Feb 2012 12:41:21 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 04E4E21E80E2 for <marf@ietf.org>; Tue, 14 Feb 2012 12:41:21 -0800 (PST)
Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 14 Feb 2012 12:41:20 -0800
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 14 Feb 2012 12:41:20 -0800
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: Message Abuse Report Format working group <marf@ietf.org>
Date: Tue, 14 Feb 2012 12:41:19 -0800
Thread-Topic: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back
Thread-Index: AczrV84Ta5lBGFryQ+G3bJVKhJWRcAAAGgyQ
Message-ID: <F5833273385BB34F99288B3648C4F06F19C9A7DD6E@EXCH-C2.corp.cloudmark.com>
References: <CAC4RtVDt5GZCQXO2p-u8mkqnOFDpMMdWvZHZJu3bU=QJOBr4vA@mail.gmail.com> <6.2.5.6.2.20120214112826.09ec1d48@resistor.net>
In-Reply-To: <6.2.5.6.2.20120214112826.09ec1d48@resistor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back
X-BeenThere: marf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Message Abuse Report Format working group discussion list <marf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/marf>, <mailto:marf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/marf>
List-Post: <mailto:marf@ietf.org>
List-Help: <mailto:marf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/marf>, <mailto:marf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2012 20:41:21 -0000

As Barry said, this document is back to being in plain old "WG Document" as we take another round of developing it.

> -----Original Message-----
> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of SM
> Sent: Tuesday, February 14, 2012 12:33 PM
> To: Message Abuse Report Format working group
> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as... expired, and coming back
> 
> The title mentions "An Applicability Statement for the Abuse Reporting
> Format".  I don't see that mentioned in the Abstract Section.

Easily fixed.

> From RFC 2606, "An Applicability Statement specifies how, and under
> what circumstances, one or more TSs may be applied to support a
> particular Internet capability".  This draft updates RFC 5965, a
> Proposed Standard.  Why is this draft an Applicability Statement?

I think it fits that definition.  The "Updates" is appropriate in that if one is implementing RFC5965, one should also read this draft.

> In Section 2, I suggest "POP3" instead of "POP".

OK.

> In the first paragraph of Section 6, "identify".
> 
>     "The Mailbox Provider SHOULD process the reports to improve its
>      spam filtering systems."
> 
> This is not required for interoperability.

Sounds like a job for the non-normative SHOULD-like words draft!

>    "3.  The Mailbox Provider SHOULD send reports to relevant parties who
>         have requested to receive such reports.  To implement the
>         recommendations of this memo, the reports MUST be formatted per
>         [RFC5965], and transmitted as an email message ([RFC5322]),
>         typically using SMTP ([RFC5321]).  The process whereby such
>         parties may request the reports is discussed in Section 3.5 of
>         [RFC6449]."
> 
> Picking the above as an example, Section 3.5 of RFC 6449 discusses
> about "Handling Requests to Receive Feedback".  I would reference the
> technology, e.g. RFC 5321, and document requirements about how the
> technology should be used.  The text quoted above comes out as a BCP.

I'm not sure what you're getting at here.  Do we need to be specific about how SMTP is used in the feedback report context?  I don't think we have any specific advice there.

> In Section 7, first paragraph, "identify".  Same for Section 8.

OK.

> In Section 9:
> 
>    "command SHOULD use the NULL return address"
> 
> That should be Reverse-Path.

OK.

> I am confused after reading the draft.  It comes out as a mix of
> recipes.  IETF practice is to send text.  I don't know where to start.

So this isn't the first time I've heard that about the current WG version.  The contention appears to be around how much detail is appropriate for this document.

Since we're back to "WG Document" state for this one, I wonder if taking the current WG version and doing a better job of organizing the information without actually removing anything would make it more palatable rather than drastically reducing the detail directly.

-MSK