Re: [marf] Proposed changes to draft-ietf-marf-as

Alessandro Vesely <vesely@tana.it> Thu, 26 April 2012 16:16 UTC

Return-Path: <vesely@tana.it>
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 81E1221E8120 for <marf@ietfa.amsl.com>; Thu, 26 Apr 2012 09:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.635
X-Spam-Level:
X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
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 E0k21XiDLYpY for <marf@ietfa.amsl.com>; Thu, 26 Apr 2012 09:16:21 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0742B21F863E for <marf@ietf.org>; Thu, 26 Apr 2012 09:16:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1335456970; bh=OG8lsKt4Ta4yBsX7jUwwmsutM7sCN43cnb2MNNEJX7g=; l=1807; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=WLrekz+lE4u06HR99iOdo75LmlJLKeLRav42GezUDHErKoRXFoa+E1bQscKYzMVcF AlD4yLR424oI7AlLe9R2g1ES1I4HP9n2P0HppKn+be8E0omxHJmB4OqeZtQL0TKM75 +CWw5BqG5dxxIJy3b4A520yCze/8UwZsctyx8afA=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 26 Apr 2012 18:16:10 +0200 id 00000000005DC039.000000004F9974CA.0000788F
Message-ID: <4F9974CA.7040501@tana.it>
Date: Thu, 26 Apr 2012 18:16:10 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
References: <9452079D1A51524AA5749AD23E003928101C5B@exch-mbx901.corp.cloudmark.com> <4F97BEAE.9000707@tana.it> <4F9883CA.9050502@cisco.com>
In-Reply-To: <4F9883CA.9050502@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: marf@ietf.org
Subject: Re: [marf] Proposed changes to draft-ietf-marf-as
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: Thu, 26 Apr 2012 16:16:23 -0000

Hi Benoit:

On Thu 26/Apr/2012 17:15:49 +0200 Benoit Claise wrote:
> 
> I prefer your proposal very much, as it addresses my questions (asked
> part of my review):

Thanks.  The question it in turn raises, however, is whether a crash
course on TS and AS intricacies is a worthy answer to the doubts that
those documents' differing categorizations might generate.

>     Can you please also a few sentences on how the documents match and
>     differ.
>     You know, I see rfc6449, published a few months back, and I see
>     this document draft-ietf-marf-as-14, which will be published
>     approx. 6 months
>     And I'm wondering, as someone not involved in this WG...
>     - Why do we have two almost similar documents?
>     - Why RFC 6449 could not be a MARF document?

In addition to what SM pointed out, let me note that it was a WG
decision to proceed that way.  See e.g.
http://www.ietf.org/mail-archive/web/marf/current/msg00980.html

>     - Which one(s) should I read?

Possibly both, or the AS and the 6449 sections it refers.

>     - Are they conflicting? If yes, I guess that draft-ietf-marf-as-14
>     take precedence. If no, is draft-ietf-marf-as-14 is superset of
>     RFC 6449, and RFC 6449 should not be read any longer.

They're not in conflict.  However, the MAAWG document is clearly
focused on quite large mailbox providers.  Unsolicited reports, that
were relegated to an appendix, have been expanded so as to bring abuse
reporting within the reach of mailbox providers of any size.
Unsolicited reports can be viewed as auto subscriptions to a feedback
loop stream of solicited reports.  RFC 6449's detailed descriptions
apply to the latter topic.

Authentication failure is a somewhat unrelated use case, factored from
other WG documents, that was conveniently added here later.

hth