Re: Last Call: <draft-jdfalk-maawg-cfblbcp-02.txt> (Complaint Feedback Loop Operational Recommendations) to Informational RFC

Barry Leiba <barryleiba@computer.org> Fri, 14 October 2011 13:14 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3779621F8C3C for <ietf@ietfa.amsl.com>; Fri, 14 Oct 2011 06:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 ndbYOQz0YkZz for <ietf@ietfa.amsl.com>; Fri, 14 Oct 2011 06:14:44 -0700 (PDT)
Received: from mail-yx0-f170.google.com (mail-yx0-f170.google.com [209.85.213.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9093D21F8C3A for <ietf@ietf.org>; Fri, 14 Oct 2011 06:14:37 -0700 (PDT)
Received: by yxl31 with SMTP id 31so1040680yxl.15 for <ietf@ietf.org>; Fri, 14 Oct 2011 06:14:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4PlDaO7sGecIkxYsUILYu5Zb200QIYWVhscT1gmzMik=; b=iD486Uy1htqzsKfV7lH/HXN308kjeg3zL3BDMNBu4VJSkCjPiQCfSyRcRRy5y2CWqr cBKAEzyN0QOlpyeMtq9+9ohu5+63Ef11ZDPbbd5lCoi3S5HAp5ZYq3C8Ea4pmxxcZKnE AI7xvgkXKPM38J2GjDr+c5UEs39B+49V6iUn4=
MIME-Version: 1.0
Received: by 10.236.185.195 with SMTP id u43mr11744717yhm.43.1318598077182; Fri, 14 Oct 2011 06:14:37 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.236.42.198 with HTTP; Fri, 14 Oct 2011 06:14:36 -0700 (PDT)
In-Reply-To: <4E97D434.8030402@qualcomm.com>
References: <20110922134311.28658.88510.idtracker@ietfa.amsl.com> <6.2.5.6.2.20111003005127.09464a50@resistor.net> <F5833273385BB34F99288B3648C4F06F19C45D9E13@EXCH-C2.corp.cloudmark.com> <CAC4RtVAyyPKjxPqKQKnc5qeFh-88KOT7NL0846gRTMOb9zL0rg@mail.gmail.com> <3266F4FF-761B-4A12-8F68-7F7F8EBC3090@cybernothing.org> <CALaySJJGwGparJZVxnTZUWZfU+RyVUcVfg13GPmdvr+4VAzZ5A@mail.gmail.com> <4E97D434.8030402@qualcomm.com>
Date: Fri, 14 Oct 2011 09:14:36 -0400
X-Google-Sender-Auth: d6hRwmhs72MRWgWwwhb4B5AiO1k
Message-ID: <CALaySJJhshwKu9U6GWPR30+sSmk-QPuuQADqmWjD5sx08KJxQA@mail.gmail.com>
Subject: Re: Last Call: <draft-jdfalk-maawg-cfblbcp-02.txt> (Complaint Feedback Loop Operational Recommendations) to Informational RFC
From: Barry Leiba <barryleiba@computer.org>
To: Pete Resnick <presnick@qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2011 13:14:46 -0000

>>>> He's not talking about the filename; the short title is what's printed
>>>> at the top of every page.  It comes from the "abbrev" parameter in the
>>>> "title" element in the XML.  It can be changed with an RFC Editor
>>>> note.
>
> The sponsoring AD would like to know what is desired in the RFC Editor note:
> What would you like the short title to be? "CFBL Recommendations"?

Yes, that's consistent with the main title.

> said, I'm happy to have you fix it with other items (such as
> s/codify/document, etc.) as such come up.

Of course.

> As for the "About MAAWG": Personally, I think it would be better to put the
> paragraph in the Acknowledgments section, or it could be simply put as a
> paragraph in the References section under reference [1]. I find the Last
> Call discussion pretty convincing that this text is untoward in the
> Abstract.

I think those are reasonable compromises, but, of course, I can't
speak for J.D.  I suggest moving the second paragraph of the Abstract
into a new "Introduction" section that comes first in the body (new
Section 1).  Put the footnote [1] to MAAWG there, and then put the
"about MAAWG" text in the footnote.  Everyone understand that?  Makes
sense?  I think that works better than putting it in the Acks.

So it would look like this:
-----------------------------------
Abstract
   (First paragraph of current abstract.)

Status of this Memo
   (boilerplate)

Copyright Notice
   (boilerplate)

Table of Contents
   (as generated)

1. Introduction

   This paper is the result of cooperative efforts within the Messaging
   Anti-Abuse Working Group [1], a trade organization separate from the
   IETF.  The original MAAWG document upon which this document is
   based was published in April, 2010.  While not originally written as an
   Internet Draft, it has been contributed to the IETF standards
   repository in order to make it easier to incorporate this material
   into IETF work.

2. Glossary of Standard Terms
   (as current)

...etc...

9. References
   (citations as current)

   [1]  MAAWG <http://www.maawg.org/> is the largest global industry
   association working against Spam, viruses, denial-of-service attacks
   and other online exploitation.  Its' members include ISPs, network
   and mobile operators, key technology providers and volume sender
   organizations.  It represents over one billion mailboxes worldwide
   and its membership contributed their expertise in developing this
   description of current Feedback Loop practices.

   [2] (as current; etc)
-----------------------------------

> Unlike Eliot, I am not as worried about substantive content complaints.
> These are recommendations from MAAWG, and they are being published as an
> informational, non-consensus document so that a WG can refer to the
> document. Such a WG may agree with all of the recommendations, but more
> likely will have some alternative advice when referring to this document.

Exactly, and that's what MARF is doing.  So, yes, I agree with this approach.

Barry