Subject: Re: [marf] Benoit Claise's Discuss on draft-ietf-marf-as-14: (with DISCUSS and COMMENT)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Apr 2012 23:33:45 +0000

> -----Original Message-----
> From: Benoit Claise [mailto:[email-masked]]
> Sent: Monday, April 23, 2012 2:45 AM
> To: The IESG
> Cc: [email-masked]; [email-masked]
> Subject: Benoit Claise's Discuss on draft-ietf-marf-as-14: (with
> DISCUSS and COMMENT)
> 
> Benoit Claise has entered the following ballot position for
> draft-ietf-marf-as-14: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> DISCUSS-DISCUSS
> 
> Abstract
> 
>    RFC 5965 defines an extensible, machine-readable format intended for
>    mail operators to report feedback about received email to other
>    parties.  This Applicability Statement describes common methods for
>    utilizing this format for reporting both abuse and authentication
>    failure events.  Mailbox Providers of any size, mail sending
>    entities, and end users can use these methods as a basis to create
>    procedures that best suit them.  Some related optional mechanisms are
>    also discussed.
> 
> Before reviewing this draft, I browsed through the 4 RFCs at
> http://datatracker.ietf.org/wg/marf/
> Question: is this intentional that the abstract and the draft only
> mention the "abuse" and "auth-failure" Feedback Type Name, and not the
> others ones?
> 	fraud 		[RFC5965]
> 	not-spam	[RFC6430]
> 	virus		[RFC5965]
> 
> Not a single reference to fraud, not-spam, virus, and [RFC6430] I'm
> surprised not to see the full ARF capacities mentioned in a document
> titled "An Applicability Statement for the Abuse Reporting Format
> (ARF)", and would like to understand.

We've simply not seen enough use of these in the wild to be able to comment on their proper or recommended use in this AS.  The original document that became RFC5965 actually listed a large number of other report types that were at one time thought to be useful, but were removed prior to publication because nobody had used them.  "fraud" and "virus" did see rare use but remain edge cases, so they remained in the list registered by RFC5965.

We can (and probably should) mention this in the Introduction.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> - I see a lot of sentences such as "... discussed in Section X of
> [RFC6449]."
> And the only sentence in the introduction related to that RFC is:
> "Further introduction to this topic may be found in [RFC6449]."
> Some sentences explaining what this informational RFC is about would be
> very welcome.

I propose this as the last paragraph to the Introduction:

Further introduction to this topic may be found in <xref target="RFC6449"/>, which is effectively an Applicability Statement written outside of the IETF and thus never achieved IETF consensus.  Much of the content for that document was input to this one.

> - please expand SPF

OK, and will do for DKIM as well.

> - Section 5.2
> "RFC5321.MailFrom" Doesn't read right to me in: "If a Feedback Provider
> applies SPF to arriving messages, a report SHOULD NOT be generated to
> the RFC5321.MailFrom domain"

It's a notation introduced in RFC5598, which is a normative reference here.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Wed, 25 Apr 2012 07:46:57 -0400

> Let me ask a very basic question to everybody, including the other IESG
> members: what is the goal of an Applicability Statement?
> 1. Explain how the technical specifications are used "in the wild", as you
> mentioned. So a deployment experience document
> 2. Or explain how the technical specifications should be used for the
> different use cases (generally specified in a requirement document)
>
> When I read RFC 2026 section 3.2, I conclude for 2.

Yes, 2.  But an AS doesn't necessarily (perhaps usually doesn't) cover
every use case.  Consider the greylisting document that's also on this
week's telechat: it's describing how to use SMTP for a specific use
case, to do a specific thing.  Many AS documents will be of that
nature, talking about certain use cases, but not every possible one.

> Therefore, I'm in favor to mention how fraud, not-spam, virus should be
> used.

The working group chose to center the marf-as document on the cases
that are actually in use today.  I think that's a fine choice.  It
might be reasonable to have one or more AS documents about the
less-common use cases, and that/those could be written later.  This
isn't that document.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 25 Apr 2012 08:45:27 -0400

> https://datatracker.ietf.org/doc/draft-ietf-appsawg-greylisting/ is
> different, as its scope is well defined, starting with the title: "Email
> Greylisting: An Applicability Statement for SMTP"
> On the other hand, "Creation and Use of Email Feedback Reports: An
> Applicability Statement for the Abuse Reporting Format (ARF)" points to a
> generic ARF application statement... which is not.

Hm.  This doesn't cover all use cases for ARF any more than
greylisting covers all use cases for SMTP, so I don't see the point.
But I'll leave it to Murray to respond further on this.  Maybe he has
some other thoughts.[1]

Barry

[1] Well, of course, he does... but I mean thoughts related to this point.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Apr 2012 14:20:00 +0000

> Sent: Wednesday, April 25, 2012 3:04 AM
> To: Murray S. Kucherawy
> Cc: The IESG; [email-masked]; draft-ietf-marf-
> [email-masked]; [email-masked]; me
> Subject: Re: Benoit Claise's Discuss on draft-ietf-marf-as-14: (with
> DISCUSS and COMMENT)
> 

We would have if we had that information, but we don't.  As I mentioned in the Introduction for -15, they are either too new (not-spam) or see too little use for us to comment on them in this document in a useful way.

I don't know what we could do beyond saying that explicitly, which we've done, apart from delaying this document until we have that experience, which could theoretically be never.

If we do want it to advance, then I'm happy to hear suggestions about what text we could add that satisfies your concern.  Is it really just the title?

> Let me discuss this during the IETF telechat tomorrow, see what the
> others are thinking, and get back to you.

OK.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 25 Apr 2012 19:51:52 +0200

> nature, talking about certain use cases, but not every possible one.

This is not the first time I see exchanges of clarifications on this
topic among people whom I consider IETF experts.  So, I'm worried what
will average readers of this document be able to conclude if they
happen to wonder about the status of the recommendations made or
referred to therein.  I doubt that citing [RFC2026] suffices.

That was the sense of my previous post,
http://www.ietf.org/mail-archive/web/marf/current/msg02329.html
in case it wasn't clear.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 25 Apr 2012 14:43:08 -0400

> referred to therein.  I doubt that citing [RFC2026] suffices.

This isn't a question of clarifications to people consuming the
document.  It's discussion among the people involved with *process*,
and it's about the process.  Once the document is published as an RFC,
consumers will see the RFC (and it will be labelled "Standards
Track"), and all this process-related discussion won't matter.

Don't worry about this point.

Barry, harried AD

---

From: Benoit Claise <[email-masked]>
Date: Wed, 25 Apr 2012 12:03:56 +0200

Hi Murray,
Let me ask a very basic question to everybody, including the other IESG 
members: what is the goal of an Applicability Statement?
1. Explain how the technical specifications are used "in the wild", as 
you mentioned. So a deployment experience document
2. Or explain how the technical specifications should be used for the 
different use cases (generally specified in a requirement document)
When I read RFC 2026 section 3.2, I conclude for 2.

Even before re-reading RFC2026, my feeling was that an applicability 
statement could be the first document that someone new to a WG could 
read: explaining the different use cases, giving pointers to the 
technical specifications, and explaining how to apply/combine the 
specifications. Basically, a document that would help implementors to 
select which (part of the) spec. to implement depending on the use case, 
a document that would promote the technology. This is how we approached 
the Applicability Statement documents in the WGs I've been involved with.

> Further introduction to this topic may be found in<xref target="RFC6449"/>, which is effectively an Applicability Statement written outside of the IETF and thus never achieved IETF consensus.  Much of the content for that document was input to this one.
Thanks. 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?
- Which one(s) should I read?
- 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.
- etc...

I'm sure you had very good answers to all these questions, and I'm 
looking for some written explanation for new comers in this space.
> It's a notation introduced in RFC5598, which is a normative reference here.
Thanks for your time and effort.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 25 Apr 2012 14:34:27 +0200

Hi Barry,
https://datatracker.ietf.org/doc/draft-ietf-appsawg-greylisting/ is 
different, as its scope is well defined, starting with the title: "Email 
Greylisting: An Applicability Statement for SMTP"
On the other hand, "Creation and Use of Email Feedback Reports: An 
Applicability Statement for the Abuse Reporting Format (ARF)" points to 
a generic ARF application statement... which is not.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 26 Apr 2012 01:09:34 +0200

Hi,

> If we do want it to advance, then I'm happy to hear suggestions about what text we could add that satisfies your concern.  Is it really just the title?
Ok, you convinced me.
Let me propose something, based on your new draft version

OLD

    At the time of publication of this document, five feedback types are
    registered.  This document only discusses two of them ("abuse" and
    "auth-failure") as they are seeing sufficient use in practice that
    applicability statements can be made about them.  The others are
    either too new or too seldomly used to be included here.

NEW

    At the time of publication of this document, five feedback types are
    registered.  This document only discusses two of them ("abuse" and
    "auth-failure") as they are seeing sufficient use in practice that
    applicability statements can be made about them.  The others, i.e. "fraud"
    RFC5965], "not-spam"	[RFC6430], and "virus"[RFC5965] are
    either too new or too seldomly used to be included here.

These simple pointers would help addressing my previous point:

    "Even before re-reading RFC2026, my feeling was that an
    applicability statement could be the first document that someone new
    to a WG could read: explaining the different use cases, giving
    pointers to the technical specifications, and explaining how to
    apply/combine the specifications. Basically, a document that would
    help implementors to select which (part of the) spec. to implement
    depending on the use case, a document that would promote the
    technology. This is how we approached the Applicability Statement
    documents in the WGs I've been involved with. "

Thanks for work on this draft.

Regards, Benoit.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Apr 2012 23:11:30 +0000

Added for -16.

-MSK

From: Benoit Claise [mailto:[email-masked]]
Sent: Wednesday, April 25, 2012 4:10 PM
To: Murray S. Kucherawy
Cc: [email-masked]; [email-masked]; The IESG; [email-masked]
Subject: Re: Benoit Claise's Discuss on draft-ietf-marf-as-14: (with DISCUSS and COMMENT)

Hi,

-----Original Message-----

To: Murray S. Kucherawy

Cc: The IESG; [email-masked]<mailto:[email-masked]>; draft-ietf-marf-

[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; me

DISCUSS and COMMENT)

used.

OLD

NEW

These simple pointers would help addressing my previous point:
"Even before re-reading RFC2026, my feeling was that an applicability statement could be the first document that someone new to a WG could read: explaining the different use cases, giving pointers to the technical specifications, and explaining how to apply/combine the specifications. Basically, a document that would help implementors to select which (part of the) spec. to implement depending on the use case, a document that would promote the technology. This is how we approached the Applicability Statement documents in the WGs I've been involved with. "
Thanks for work on this draft.

Regards, Benoit.

OK.

-MSK

---

From: SM <[email-masked]>
Date: Wed, 25 Apr 2012 16:57:22 -0700

Hi Benoit,
At 03:03 25-04-2012, Benoit Claise wrote:
>Let me ask a very basic question to everybody, including the other 
>IESG members: what is the goal of an Applicability Statement?

That was the question which comes to mind on reading the DISCUSS-DISCUSS.

>1. Explain how the technical specifications are used "in the wild", 
>as you mentioned. So a deployment experience document
>2. Or explain how the technical specifications should be used for 
>the different use cases (generally specified in a requirement document)

That section mentions Technical Specification.   The Applicability 
Statement was about restricted "domain of applicability" when using 
the Technical Specification.

One little quirk is:

   "An AS may not have a higher maturity level in the standards track
    than any standards-track TS on which the AS relies (see section 4.1).
    For example, a TS at Draft Standard level may be referenced by an AS
    at the Proposed Standard or Draft Standard level, but not by an AS at
    the Standard level."

There are a few other quirks.  Whether they are relevant or not 
depends on whether one wants to cherry-pick what's in RFC 2606.

Regards,
-sm

---

From: Pete Resnick <[email-masked]>
Date: Wed, 25 Apr 2012 19:06:40 -0500

On 4/25/12 5:03 AM, Benoit Claise wrote:
>> Further introduction to this topic may be found in<xref 
>> target="RFC6449"/>, which is effectively an Applicability Statement 
>> written outside of the IETF and thus never achieved IETF consensus.  
>> Much of the content for that document was input to this one.
> - 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.
> - etc...
>

After chatting with Benoit offline, I now believe that your addition 
actually increased confusion rather than decreased. What I think you 
want to say is something like, "Further introduction to this topic may 
be found in 6449, which has more information about the general topic of 
abuse reporting. Many of the specific ARF guidelines in this document 
were taken from the principles presented in 6449." The text you've got 
now 'buries the lead'.

Not required, but I think this might help.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 26 Apr 2012 02:07:34 +0000

> From: Pete Resnick [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2012 5:07 PM
> To: Benoit Claise
> Cc: Murray S. Kucherawy; [email-masked]; marf-
> [email-masked]; The IESG; [email-masked]

I'm fine with that if you want to do it as an RFC Editor note.  If you need a -17, let me know.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Apr 2012 22:31:46 -0400

> I'm fine with that if you want to do it as an RFC Editor note.  If you need

If you do a -17, please fix the believe thing too.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 26 Apr 2012 05:06:10 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Wednesday, April 25, 2012 7:32 PM
> To: [email-masked]
> Subject: Re: [marf] Benoit Claise's Discuss on draft-ietf-marf-as-14:
> (with DISCUSS and COMMENT)
> 

Yes, I'll include that in either -17 or the RFC Editor request.

-MSK

---

From: Pete Resnick <[email-masked]>
Date: Thu, 26 Apr 2012 11:30:02 -0500

> Yes, I'll include that in either -17 or the RFC Editor request.

Murray, please give me OLD/NEW for these two changes and I'll put it in 
the RFC Editor notes. I'd rather not have a -17 in this particular case.

pr

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 26 Apr 2012 17:05:12 +0000

> Sent: Thursday, April 26, 2012 9:30 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [marf] Benoit Claise's Discuss on draft-ietf-marf-as-14: (with DISCUSS and COMMENT)
> 

Ask and ye shall receive.

OLD (Section 1):

   Further introduction to this topic may be found in [RFC6449], which
   is effectively an Applicability Statement written outside of the IETF
   and thus never achieved IETF consensus.  Much of the content for that
   document was input to this one.

NEW:

   Further introduction to this topic may be found in [RFC6449], which
   has more information about the general topic of abuse reporting.  Many
   of the specific ARF guidelines in this document were taken from the
   principles presented in [RFC6449].

OLD (Section 5.1):

   2.  Message authentication is generally a good idea, but it is
       especially important to encourage credibility of and thus
       response to unsolicited reports.  Therefore, as with any other
       message, Feedback Providers sending unsolicited reports SHOULD
       send reports that they believe will pass Sender Policy Framework
       ([RFC4408]) and/or DomainKeys Identified Mail ([RFC6376]) checks.

NEW:

   2.  Message authentication is generally a good idea, but it is
       especially important to encourage credibility of and thus
       response to unsolicited reports.  Therefore, as with any other
       message, Feedback Providers sending unsolicited reports SHOULD
       send reports that they expect will pass Sender Policy Framework
       ([RFC4408]) and/or DomainKeys Identified Mail ([RFC6376]) checks.

-MSK

---

From: Benoit Claise <[email-masked]>
Date: Thu, 26 Apr 2012 11:41:27 +0200

On 26/04/2012 02:06, Pete Resnick wrote:
>> Thanks. Can you please also a few sentences on how the documents 
>> match and differ.
> be found in 6449, which has more information about the general topic 
> of abuse reporting. Many of the specific ARF guidelines in this 
> document were taken from the principles presented in 6449." 
That works for me.

Regards, Benoit.
> The text you've got now 'buries the lead'.
>