On 14/Feb/12 05:57, Scott Kitterman wrote: > On Monday, February 13, 2012 03:43:11 PM John Levine wrote: > >> 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. > > 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.
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. > If you look at the old paragraph 8.6 of the AS draft, it says: > > 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). > > 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 (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. _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
