Hi Murray,
-----Original Message-----
From: Benoit Claise [mailto:[email protected]]
Sent: Monday, April 23, 2012 2:45 AM
To: The IESG
Cc: [email protected]; [email protected]
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.
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.
Therefore, I'm in favor to mention how fraud, not-spam, virus should be
used.
Let me discuss this during the IETF telechat tomorrow, see what the
others are thinking, and get back to you.
----------------------------------------------------------------------
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.
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.
- 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.
Thanks for your time and effort.
Regards, Benoit.
-MSK
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
