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 protected] [mailto:[email protected]] 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. > 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? 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. > 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. Sounds like a job for the non-normative SHOULD-like words draft! > "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. 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. > In Section 9: > > "command SHOULD use the NULL return address" > > That should be Reverse-Path. OK. > 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. 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 _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
