On 24/Feb/12 22:12, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > > A co-chair's note: At this point I think it's prudent to say we > won't make any more changes unless they achieve rough consensus or > they are merely minor editorial corrections. > >> *Solicited and Unsolicited Reports* >> >> Section 3 may sound misleading, as it may seem to exclude that >> unsolicited reports may also be "due to recipients manually reporting >> messages as spam." (The introduction can be understood both ways.) > > Making a backward reference about the cause of the reports from the > second paragraph to the first is possibly a simpler change than > what you propose, i.e.: > > "Other uses for ARF involve such reports sent between parties that > don't know each other." > > Is that sufficient?
Ehm, possibly; my English doesn't support me quite enough. If "such" unambiguously refers to the same reports that the first paragraph alludes to, then it is sufficient. >> (Really, solicited/unsolicited sending is transparent to the user or >> any other stream-wise similar input mechanisms. Is it too late to try >> and treat #1 of Section 4.1 and #2 of Section 6.2 in a unified common >> section?) > > I'm somewhat partial against having a "common" section. What do > others think? This subject is peculiar in that the I-D does not specify it at all. This consideration can justify a different editorial arrangement. > Also, what do others think of the idea of talking about spam traps > in Section 4.1? It doesn't seem to me as though it's advice > specific to unsolicited reports, unless that would be something > covered in the agreement implicated in a solicited feedback > arrangement. Viruses is a similar idea, left as a hint. But hinting twice would become pushing. >> *When To Generate Reports* >> >> The title of Section 6.2 should more appropriately be "When /Not/ To >> Generate Reports", except for the last paragraph that matches neither >> title. How about moving #5 to the previous (General Considerations) >> subsection? > > I don't agree with the renaming, but I agree with the proposed > rearrangement. Fine. > Others? ... >> *Where To Send Reports* >> >> SPF doesn't sign. In paragraph #4 of Section 6.3, I'd replace: >> >> Where an abusive message is signed using a domain-level >> authentication technology such as DKIM ([RFC6376]) or SPF >> ([RFC4408]), the domain that has been verified by the >> >> with: >> >> Where an abusive message is authenticated using a domain-level >> authentication technology such as DKIM ([RFC6376]) or SPF >> ([RFC4408]), the domain that got a "pass" ([RFC5451]) by the >> >> (Is it possible to cite IANA's "Email Authentication Result Names" >> rather than, or in addition to, [RFC5451]?) > > I agree with changing "signed" to "authenticated", but I think the > rest goes too far without making the point any more clearly. IMHO, it'd be very pertinent to include RFC 5451 among normative references, because of the pivotal role that it plays in reports generation of both types. As for leaving "pass" implied rather than explicit, it is consistent with presenting targets selection as an heuristic process, so I can live with it. >> *What To Do With Reports* >> >> No vacation replies. In paragraph #4 of Section 6.5, I'd replace: >> >> a reply might be desirable to indicate that the complaint will >> result in action >> >> with: >> >> a non-automated reply might be desirable to indicate what action >> resulted from the complaint > > I agree with that one. Thank you. _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
