On Sunday, February 12, 2012 07:42:05 PM Murray S. Kucherawy wrote: > Hi all, > > A last-minute rewrite of a couple of sections of draft-ietf-marf-as was > submitted. The feeling is that Sections 7 and 8 (especially the latter) > had become too verbose and confusing, and had the feel of micromanagement. > The proposed text is rather more general while still attempting to put the > working group's main message into the hands of feedback operators. > > The diff is here: http://www.blackops.org/~msk/marf-as.html > > Please review it and comment as soon as possible. This is our last batch of > work before Barry can write up his shepherding document and move it along > to the IESG.
This is a substantial change and I don't think it is reasonable to assume that any working group consensus established during the recently completed last call would apply to it. I like the consolidation of 7.4, 7.5, and 7.7 with 7.3, but I think it goes a little too far. I think the MUST/SHOULD NOTs in the original 7.4 are significant. I'm less fond of the changes to paragraph 8. I think the advice that was removed in 8.1 was useful. I don't think that what makes a report actionable is broadly understood, so including that discussion is useful. Removal of the previous 8.3 is concerning as I think people are encouraged enough to send reports to reports and about resources that are at most peripherally involved in abuse. I think discouraging this sort of behavior for high volume automatic abuse reports that are unsolicited is important. It would be good to understand the rationale for removing the reference to WHOIS abuse addresses? Other heuristics are retained to some degree, but that one was dropped completely. I think the revised discussion about DKIM and SPF is unintelligible. I think the old 8.5 and 8.6 gave explanations that are useful for developers that are not DKIM or SPF experts. The revised text will only provide value for people who already know about DKIM or SPF (i.e. the people that don't need the text because they know already) or people that are triggered to go become protocal experts for DKIM and SPF to figure out how to apply them to this problem. If this is retained the relevant DKIM and SPF RFCs should be normative as there's no way to properly implement this without a detailed study of them now. I particularly object to ditching 8.6. We had a lot of discussion and iterated through a lot of options before settling on the current wording as the rough consensus of the group. One of the primary reasons for the creation of SPF was to reduce the amount of unwanted blowback due to bounce messages when domains where forged. Without clear guidance about this, this draft could cause high volume unsolicited ARFs that cause very similar problems to the bounces from forged messages the protocol was created to combat. Please don't. I think the simplification relative to the old 8.8 (on receiver processing) is fine. I think the removal of 8.11 and 8.12 is fine too. I think the simplification of 8.13 into 8.8 and 8.14 into 8.9 are fine. I'm OK with ditching 8.15 as I don't think it's particularly actionable. For 8.16, I don't think the simplification is an improvement, but I don't think it's awful. WHOIS is mentioned in 8.2 (new and old) so the reference should probably stay. Scott K _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
