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

"Murray S. Kucherawy" <msk@cloudmark.com> Wed, 25 April 2012 13:54 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 266FE21F872E for <marf@ietfa.amsl.com>; Wed, 25 Apr 2012 06:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.634
X-Spam-Level:
X-Spam-Status: No, score=-102.634 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 wGsd-kq5vdIo for <marf@ietfa.amsl.com>; Wed, 25 Apr 2012 06:53:59 -0700 (PDT)
Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF8A21F86FE for <marf@ietf.org>; Wed, 25 Apr 2012 06:53:58 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 2Dtc1j0010as01C01DtcSm; Wed, 25 Apr 2012 06:53:36 -0700
X-CMAE-Match: 0
X-CMAE-Score: 0.00
X-CMAE-Analysis: v=2.0 cv=MJriabll c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=DdGZrSWdj7kA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=sDN6jlLyAAAA:8 a=48vgC7mUAAAA:8 a=i3N05akNdjdLHfHm3lMA:9 a=CjuIK1q_8ugA:10 a=a5MtBNqIqo4A:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117
Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Wed, 25 Apr 2012 06:53:35 -0700
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: "marf@ietf.org" <marf@ietf.org>
Thread-Topic: [marf] Proposed changes to draft-ietf-marf-as
Thread-Index: Ac0ipHVkVfh2i6HcSRStlMqNZFB0BAAgHKAAAA6aZoA=
Date: Wed, 25 Apr 2012 13:53:35 +0000
Message-ID: <9452079D1A51524AA5749AD23E003928102204@exch-mbx901.corp.cloudmark.com>
References: <9452079D1A51524AA5749AD23E003928101C5B@exch-mbx901.corp.cloudmark.com> <5386985.GhKIFnpsVj@scott-latitude-e6320>
In-Reply-To: <5386985.GhKIFnpsVj@scott-latitude-e6320>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [67.160.203.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335362016; bh=EMn/S9zxTnB1BTDweFBRtbDVZ/Vn/w6mv4in2ucULxM=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=IJhUgv7rhxgCw2AGVyyrEA4gMpclNhTjlXcU8y6CQcV5L3falAAzipRv6IaBV6ewQ ri0BPJiWe77NwmhJL0umpuCpQdM+QTV4rcth+7noqeoaF3YG7QXJYV3TuxOxTCG3yN jC+gQ8tayI8CGr6YjuZYf+B/rxxrBHy7+3xq0Pcg=
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: Wed, 25 Apr 2012 13:54:02 -0000

> -----Original Message-----
> From: Scott Kitterman [mailto:sklist@kitterman.com]
> Sent: Wednesday, April 25, 2012 6:49 AM
> To: marf@ietf.org
> Cc: Murray S. Kucherawy
> Subject: Re: [marf] Proposed changes to draft-ietf-marf-as
> 
> I don't find much value in the changes, but if that's what it takes to
> get approved, OK.  A few specific comments though:
> 
>  - The addition to section 4.5.1 isn't quite correct.  Elsewhere we
> tell report senders not to assume different types of reports will be
> treated differently, so I don't think there's any need for receivers to
> update to do so.  I think the most that can be said is that receivers
> ought to arrange for a reasonable default result if an unknown type is
> encountered.

There issue is that we make it a MUST to accept all types listed in a registry.  How would an implementation do that?  There's no protocol to query the registry for new types, so it can't really be done live.  The IESG member is saying we need to explain to people what's involved in satisfying that MUST.

>  - Part of the diff starting page 7, line 4: How about anticipate or
> expect instead of believe.  Belief isn't much of an engineering term.

Good point.  We can patch that up with an RFC Editor note, unless another new version is warranted.

-MSK