Subject: [marf] Simplifying draft-ietf-marf-as

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 12 Feb 2012 19:42:05 -0800

Hi all,

A last-minute rewrite of a couple of sections of draft-ietf-marf-as was submitted.  The feeling is that Sections 7 and 8 (especially the latter) had become too verbose and confusing, and had the feel of micromanagement.  The proposed text is rather more general while still attempting to put the working group's main message into the hands of feedback operators.

The diff is here: http://www.blackops.org/~msk/marf-as.html

Please review it and comment as soon as possible.  This is our last batch of work before Barry can write up his shepherding document and move it along to the IESG.

Thanks,
-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 12 Feb 2012 23:24:36 -0500

On Sunday, February 12, 2012 07:42:05 PM Murray S. Kucherawy wrote:
> Hi all,
> 
> A last-minute rewrite of a couple of sections of draft-ietf-marf-as was
> submitted.  The feeling is that Sections 7 and 8 (especially the latter)
> had become too verbose and confusing, and had the feel of micromanagement. 
> The proposed text is rather more general while still attempting to put the
> working group's main message into the hands of feedback operators.
> 
> Please review it and comment as soon as possible.  This is our last batch of
> work before Barry can write up his shepherding document and move it along
> to the IESG.

This is a substantial change and I don't think it is reasonable to assume that 
any working group consensus established during the recently completed last 
call would apply to it.

I like the consolidation of 7.4, 7.5, and 7.7 with 7.3, but I think it goes a  
little too far.  I think the MUST/SHOULD NOTs in the original 7.4 are 
significant.

I'm less fond of the changes to paragraph 8.  I think the advice that was 
removed in 8.1 was useful.  I don't think that what makes a report actionable 
is broadly understood, so including that discussion is useful.

Removal of the previous 8.3 is concerning as I think people are encouraged 
enough to send reports to reports and about resources that are at most 
peripherally involved in abuse.  I think discouraging this sort of behavior 
for high volume automatic abuse reports that are unsolicited is important.

It would be good to understand the rationale for removing the reference to 
WHOIS abuse addresses?  Other heuristics are retained to some degree, but that 
one was dropped completely.

I think the revised discussion about DKIM and SPF is unintelligible.  I think 
the old 8.5 and 8.6 gave explanations that are useful for developers that are 
not DKIM or SPF experts.  The revised text will only provide value for people 
who already know about DKIM or SPF (i.e. the people that don't need the text 
because they know already) or people that are triggered to go become protocal 
experts for DKIM and SPF to figure out how to apply them to this problem.  If 
this is retained the relevant DKIM and SPF RFCs should be normative as there's 
no way to properly implement this without a detailed study of them now.

I particularly object to ditching 8.6.  We had a lot of discussion and 
iterated through a lot of options before settling on the current wording as 
the rough consensus of the group.  One of the primary reasons for the creation 
of SPF was to reduce the amount of unwanted blowback due to bounce messages 
when domains where forged.  Without clear guidance about this, this draft 
could cause high volume unsolicited ARFs that cause very similar problems to 
the bounces from forged messages the protocol was created to combat.  Please 
don't.

I think the simplification relative to the old 8.8 (on receiver processing) is 
fine.  I think the removal of 8.11 and 8.12 is fine too.  I think the 
simplification of 8.13 into 8.8 and 8.14 into 8.9 are fine.  I'm OK with 
ditching 8.15 as I don't think it's particularly actionable.  For 8.16, I 
don't think the simplification is an improvement, but I don't think it's awful.

WHOIS is mentioned in 8.2 (new and old) so the reference should probably stay.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 13 Feb 2012 16:15:27 +0100

On 13/Feb/12 04:42, Murray S. Kucherawy wrote:
> Please review it and comment as soon as possible.  This is our last
> batch of work before Barry can write up his shepherding document and
> move it along to the IESG.

That oversimplifies the I-D.  Except for a few excisions, version -08
looks sounder and clearer.

In the rest of this message, I paste all the snippets of text that,
IMHO, can be removed from Section 8 of version -08 with no substantial
loss:

 The following advice is offered for the case of reports that are not
 solicited:

                                                         (These
      applications might be described in future IETF documents.)
      Systems SHOULD NOT report all mail sent from a particular sender
      merely because some of it is determined to be abusive.

           since, because of their subjective nature, they are
      unlikely to provide a basis for the recipient to take action

 6.   Similarly, if a report generator applies SPF to arriving
      messages, and that evaluation produced something other than a
      "Pass", "None" or "Neutral" result, a report addressed to the
      RFC5321.MailFrom domain SHOULD NOT be generated as it is
      probably a forgery and thus not actionable.  A valid exception
      would be specific knowledge that the SPF result is not
      definitive for that domain under those circumstances (e.g., a
      message that is also DKIM-signed by the same domain, and that
      signature validates).

                                                     However, they MAY
      take advantage of the standardized parts of the ARF format to
      automate processing.

---

From: "John Levine" <[email-masked]>
Date: 13 Feb 2012 15:43:11 -0000

>The diff is here: http://www.blackops.org/~msk/marf-as.html

Steve and I went through and took out stuff that looks too much like
an implementor's guide rather than an applicability statement.  In
particular, we tried to stick to what to accomplish, not how to do it.

There's nothing wrong with writing a DKIM or SPF reporting cookbook,
but this isn't it.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Mon, 13 Feb 2012 11:02:50 -0500

> any working group consensus established during the recently completed last

I agree, and I will want to hear from at least all the participants
who made WGLC comments, before accepting this version.  So far, we've
heard from Scott and Alessandro, who aren't happy with the changes.
That's likely to mean that the document isn't ready to go yet, and
that we need more work to re-achieve consensus on a last-call version.

Barry, document shepherd

---

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

On Monday, February 13, 2012 11:02:50 AM Barry Leiba wrote:
> >> had become too verbose and confusing, and had the feel of
> >> micromanagement. The proposed text is rather more general while still
> >> attempting to put the working group's main message into the hands of
> >> feedback operators.> 
> > This is a substantial change and I don't think it is reasonable to
> > assume that any working group consensus established during the recently
> > completed last call would apply to it.
> 

That or decide there's rough consensus on the previous draft.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 13 Feb 2012 21:38:43 -0500

> There's nothing wrong with writing a DKIM or SPF reporting cookbook,

Where are applicability statements defined?

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 13 Feb 2012 19:54:28 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Monday, February 13, 2012 6:39 PM
> To: [email-masked]
> Subject: Re: [marf] Simplifying draft-ietf-marf-as
> 

Section 3.2 of RFC2026.

---

From: "John Levine" <[email-masked]>
Date: 14 Feb 2012 04:02:11 -0000

>Where are applicability statements defined?

RFC 2026, sections 3.2 and 3.3.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 13 Feb 2012 23:57:06 -0500

> There's nothing wrong with writing a DKIM or SPF reporting cookbook,

OK.  Now that I've read the relevant standard, I'm more convinced than ever 
this proposed change is a step in the wrong direction.  The first section of 
RFC 2026, paragraph 3.2 says:

   An Applicability Statement specifies how, and under what
   circumstances, one or more TSs may be applied to support a particular
   Internet capability.  An AS may specify uses for TSs that are not
   Internet Standards, as discussed in Section 7.

If you look at the old paragraph 8.6 of the AS draft, it says:

To me that reads exactly like a statement about how and under what 
circumstances one or more technical standards (ARF, DKIM, SPF) may be applied 
to support a particular internet capability (unsolicitited automatic abuse 
reports).

A DKIM or SPF "cookbook" would describe how to determine the SPF result.  This 
just says what to do with them.  It seems exactly right to me.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 14 Feb 2012 05:07:09 -0000

I completely disagree, but for this document, it's not worth
fighting about it.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 14 Feb 2012 12:59:46 +0100

>    Internet Standards, as discussed in Section 7.

The AS capability aims at RFC 6449, which is formally Informational
although it has the appearance and the substance of a BCP.  In facts,
it was a MAAWG's BCP, and it was decided to keep the document as-is
rather than re-discuss it anew.

Section 8 is not covered by RFC 6449, it's new stuff.  Since RFC 2026
allows an AS to also contain technical specifications, the WG thought
it's better to come out with a single RFC rather than split the
discourse into multiple documents.

> to support a particular internet capability (unsolicited automatic abuse 
> reports).

The I-D gives four possible ways to derive a target address.  It is
probably that that John refers to as "reporting cookbook".  I admit it
is rather vague and requires some wit to get right.  The style of
Section 8 is to tell what to accomplish by describing possibilities
and restraints, so as to sketch the way.  For a justification, the way
is large enough to allow some degrees of freedom, yet not so well
paved as to grant running through any path on it.  Is that style (or
level of detail) acceptable?

I propose we review the bluish-background passages in the diff, one
component at a time, starting with Section 8, making use of that cool
professionalism that we are famous for.  Given that we all share the
same goal, we can well do it within the time frame that Barry said.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 14 Feb 2012 11:26:18 -0500

> RFC 2026, paragraph 3.2 says:

I can give the WG my opinion, as a contributor, a chair, and now an
AD, on what an Applicability Statement should be.  We have little
recent experience with the AS idea -- its function has mostly been
either included in Technical Specifications (TS), pushed into a
non-standards-track Informational document (as in the DKIM operational
guide), or published as a BCP.

A TS, such as RFC 5965 (MARF base), is meant to describe the details
of the protocol, while an AS is for explaining how to use the protocol
in practice.  It's often difficult to decide where to draw the line
between what should go in the TS and what qualifies as AS material.
But I think there's a lot of flexibility in deciding what qualifies
for an AS.  As chair (and, soon, as AD), my opinion goes toward
inclusion.  The working group has to decide what it has rough
consensus to include, of course.  That said, I recommend that it
include what advice would be useful to use these protocols to best
effect and greatest level of interoperability in the real world...
considering that this advice can advance along the standards track
along with the protocol documents themselves, getting revisions as
appropriate along the way (which is one thing that distinguishes an AS
from a BCP).

Because the AS is a Standards Track document, it theoretically carries
more weight than an Informational document, and the WG should consider
what should be specified as advice on the Standards Track, and what
really *is* just information.  That said, purely informational content
can be included in the AS and be so labelled.  But stuff that's
important to getting your abuse reports done right and accepted by
report consumers should be in here.  Stuff that's important to report
consumers for correctly handling abuse reports should be in here.

I'm not sure why there's such a strong desire among some to eliminate
text, so perhaps you can explain that.  My preference (as a
participant), and my advice (as a chair) is to include more
information, as long, of course, as we think that information is
correct.  If we're cutting content because we don't agree with it, we
should do that.  If we're cutting content just to make the document
shorter, I question the need for that.  If we're cutting content
because we think an "AS" shouldn't have that sort of stuff in it,
let's think about that carefully, and explain why.  If it helps
implementors get things right and interoperate better, or helps
implementors better understand how multiple standards work together, I
think it's exactly what belongs in an AS.

Barry