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

From: Barry Leiba <[email-masked]>
Date: Mon, 13 Feb 2012 18:05:25 -0500

A couple of weeks ago-ish, I started working-group last call on the
subject document, and said this:

> Please do not
> wait until the last minute, and especially do not wait until the
> document goes to the IESG.  You will be beaten with a rubber
> truncheon.

It seems that I do need to get out my truncheon.

John Levine and Steve Atkins did, indeed, wait until the last minute.
Despite participation in the last-call conversation, they provided
*major* edits to the editor (1) off list, and (2) after WGLC ended.

Now, I'm not one to hold a line, at least not at this point, and say
that we won't consider useful input because an arbitrary deadline
wasn't met.  At the same time, this sort of behaviour is abusive to
the working group.  It abuses process, it abuses the chair's desire to
accommodate all reasonable input, and, most significantly, it shows a
complete lack of respect for the time and effort of the other
participants.  We spent ten days hashing out what some thought were
the final details of an almost-done document, only to find that a
couple of participants thought it proper to do significant rewrites at
the last minute and without discussing them with the group.

Everyone:  My interest in accommodating everyone's input and allowing
for busy schedules that include things other than MARF participation
is getting a bit frayed.

I consider that the AS document is back to "active document" state.
We will continue discussing it.  We will come to rough consensus on
all, some, or none of the recent changes.  WHen we've decided where
the working group as a collective roughitude stands on it, we will
re-do working-group last call.  And we will expect that discussion
will quickly converge so that we can send this to the IESG before the
Paris IETF meeting.

And we will NOT do this sort of thing again.

Barry, as increasingly annoyed chair

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 13 Feb 2012 19:09:20 -0500

> Barry, as increasingly annoyed chair

OK.  I've invested all the time I intend to invest in this draft within the 
working group.  I'll read it again when it hits IETF last call then.  I don't 
have time for this.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 13 Feb 2012 20:14:44 -0500

On Monday, February 13, 2012 07:09:20 PM Scott Kitterman wrote:
> working group.  I'll read it again when it hits IETF last call then.  I
> don't have time for this.

I've gone back and re-read Barry's mail and while I'm frustrated, I'm backing 
off from my last statement.  You've got my review of the proposed changeset.  
It's got a few things worth using, but on the whole, I think it worsens the 
document.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 14 Feb 2012 13:49:56 +0100

This is the first of nine (connected, blu background) diff components
of Section 8.

Section 8 starts saying that

      Systems that generate unsolicited reports SHOULD ensure that the
      criteria used to decide what messages to report accurately
      identify messages that the reporting entity believes in good
      faith are abusive.

The mutilated version just adds "and are sent only to parties that are
able to act on them".  This recommendation looks similar to the
concept in the last paragraph.  Its role here could express the
concern that messages to be reported were actually received by the
reporting entity, not forwarded from some other account.

The published version, instead, exemplifies some criteria, thereby
adding automatic triggers to the original TiS-button criterion:

                          Such criteria might include direct complaint
      submissions from MUAs, reports triggered by mail sent to "spam
      trap" or "honeypot" addresses, and virus reports.  (These
      applications might be described in future IETF documents.)

At a minimum, we should keep TiS buttons, in order to match paragraph
1 of Section 6.

IMHO, the next sentence can be safely eliminated:

      Systems SHOULD NOT report all mail sent from a particular sender
      merely because some of it is determined to be abusive.

Finally, version-08 says to avoid sending Bayesian scores:

      Mechanical reports of mail that "looks like" spam, based solely
      on the results of inline content analysis tools, SHOULD NOT be
      sent since, because of their subjective nature, they are
      unlikely to provide a basis for the recipient to take action.

IMHO, that "SHOULD NOT" is good for unsolicited reports, because
attempts to establish a reporting channel deserve solid reasons.
I don't agree on the given explanation, but can live with it.

Comments?

---

From: SM <[email-masked]>
Date: Tue, 14 Feb 2012 12:32:32 -0800

Hello,

As this is late feedback, please consider all the comments are 
optional.  The comments are based on the diff posted by Murray.

The title mentions "An Applicability Statement for the Abuse 
Reporting Format".  I don't see that mentioned in the Abstract Section.

 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?

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

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.

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

     "The reports SHOULD include the following optional fields whenever
      practical: Original-Mail-From, Arrival-Date, Source-IP, Original-
      Rcpt-To.  Other optional fields MAY be included, as the
      implementer feels is appropriate."

The above qualifies as applicability as it specifies a recommendation 
for fields which are optional in a Technical Specification.

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

In Section 9:

   "command SHOULD use the NULL return address"

That should be Reverse-Path.

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.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Feb 2012 12:41:19 -0800

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: [email-masked] [mailto:[email-masked]] 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.

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

> This is not required for interoperability.

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

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

> That should be Reverse-Path.

OK.

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Feb 2012 13:13:45 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Tuesday, February 14, 2012 12:41 PM
> As Barry said, this document is back to being in plain old "WG
> Document" as we take another round of developing it.
> [...]
> 
> 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.

Just to be clear, I am going to take a run at re-organizing the current WG version without removing any detail.  A better presentation might make it more palatable.  I'll post something new to the list soon.

---

From: SM <[email-masked]>
Date: Tue, 14 Feb 2012 13:33:15 -0800

Hi Murray,
At 12:41 14-02-2012, Murray S. Kucherawy wrote:
>I think it fits that definition.  The "Updates" is appropriate in 
>that if one is implementing RFC5965, one should also read this draft.

No, the question is why is it an AS?

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

:-)

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

No.  My point was about how to draw up an Applicability Statement 
from a Technical Specification.  Let's say that we are using RFC 5965 
for a specific purpose.  Section 3.2 of that RFC mentions optional 
fields.  An AS can make them a requirement.

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

If I understood correctly, the draft is about using ARF for 
unsolicited reports.  The two documents do not really map as this 
draft covers a wide topic.  As you mentioned above, it is a matter of 
organizing the information.  How that is done is more of an editorial choice.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 15 Feb 2012 13:40:55 +0100

> No, the question is why is it an AS?

My understanding is^H^H was that an AS allows to "import" a TS from
external sources.  Something like saying "Hey, that stuff is to be
considered Standard-Track, even if it's formally Informational and/or
produced outside of the IETF."

Recall the bottom paragraph of
http://www.ietf.org/mail-archive/web/marf/current/msg01257.html

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 15 Feb 2012 12:24:32 -0500

In <[email-masked]>, on 02/14/2012
   at 01:33 PM, SM <[email-masked]> said:

>unsolicited reports.

It's primarily about solicited reports.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 15 Feb 2012 12:21:31 -0500

In <[email-masked]>, on 02/14/2012

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

Then "IMAP" should be "IMAP4".

---

From: Steve Atkins <[email-masked]>
Date: Wed, 15 Feb 2012 09:58:01 -0800

> It's primarily about solicited reports.

It's about both, about equally. They're quite different things, and the
only connection between them is that they both are using ARF as
the envelope format. 

Cheers,
  Steve

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 15 Feb 2012 19:55:29 +0100

> only connection between them is that they both are using ARF as

Another connection is that one can transition from receiver of
unsolicited reports to FBL subscriber by clicking on a link in the
human readable part of (one of) the first reports.