Trying to sum up the situation here: 1. Several people have argued (somewhat convincingly) that: - Source IP address reputation services can be valuable tools for blocking spam, - Such services can be better at identifying spam than per-message content analysis, - Such services can (and sometimes do) provide better feedback to the sender, and thus better accountability, than per-message content analysis that occurs later in the signal path, and - At least some such services have very low false positive rates. It's important to keep these in mind, as they appear to make a compelling case for some kind of standardized reputation service. 2. Several people have also related experiences of valid messages being blocked by such reputation services, and of the difficulty of routing around them and getting their reputations corrected. This strongly argues for such reputation services to have strict accountability, and for there to be a clear, well-defined means by which senders can correct erroneous reputations, and to get vital messages delivered in spite of erroneous reputations. 3. An informal protocol for reporting reputations using DNS has been in use for several years, and such use has become widespread. An IRTF group (ASRG) began a useful effort to document this protocol. 4. At some point ASRG decided that the protocol should be on the IETF standards track and has requested such. -- This process that produced this proposal reminds me of several patterns I've seen come up often in IETF. 1. The first pattern is when an author or group gets confused between the goal of writing an informational document to describe existing practice, and the goal of writing a standards-track document that describes desirable practice. Offhand, I cannot recall a single experience when this has produced satisfactory results. The two goals are very much in conflict. When describing existing practice, it is very tempting to add extensions that seem to be desirable, but which in fact are not part of existing practice. This is misleading at best, and at worst can cause interoperability problems (my favorite example of this is RFC 1179). OTOH, when writing standards that are based on existing practice, it is very tempting to include existing practice (for the sake of "compatibility") within the scope of permitted behavior, even when that practice is dubious for one reason or another - poor security, say, or poor scalability. Over the years I've formed the opinion that the only reasonable way to build a standard from existing practice was to first commit to accurately documenting existing practice and publishing that document as Informational. Part of that process should be to document known limitations of that existing practice. Only after that document is completed should there be an attempt to design a standard that is compatible with existing practice. That effort needs to be treated as a design effort and subject to all of the usual vetting. Furthermore it needs to be understood that serious flaws from the original protocol must not be included in the standard for the sake of backward compatibility. 2. The second pattern is when people insist that a widely deployed protocol is inherently deserving of standardization, without further vetting or changes, merely because it is widely deployed. The simplest way of responding to this is that this is irrelevant under our process. The RFC 2026 criteria for proposed standard status require both "rough consensus" of the IETF community and "no known technical omissions". The fact that something is widely deployed may be a indication of its utility, but is not an indication of technical soundness. Nor is it an indication of consensus of the IETF technical community. 3. The third pattern is when a closed industry group, or an open group that is not chartered to develop a standard protocol, insists that its product merits standardization by IETF because it has gained consensus of that group. The problem with this is that the group did not attract the wide range of interests that would normally attend an IETF standardization effort, nor did the group operate under processes designed to ensure fairness and openness. Such efforts can be considered in the IETF process as individual submissions, but they need a great deal of scrutiny, as this tactic is often used as an "end run" around IETF. My experience with individual submissions is that simple, noncontroversial proposals affecting a small number of parties rarely present serious obstacles to standardization, but proposals that affect a large number of parties are much more difficult, and with good reason. The main point to be made here is that the consensus of an external group means nothing in terms of either IETF consensus or judgment of technical soundness. In particular, external groups often have a much narrower view of protocol requirements than IETF does. All of these patterns are associated with delays in accepting a standard. They are also associated with poorer quality standards. -- Back to the proposal at hand. We have a proposal on the table for a service which seems to have significant value if implemented properly. And yet the proposal omits many of the details that appear to be required for the service to have value, deferring those to a later "BCP" document. So there's an argument that the proposal as currently written is incomplete, and standardization of the protocol is premature at best. It is worth repeating that just because the notion of a reputation service has value, and such services are widely used, does not imply that using IP addresses as identifiers or the DNS protocol as a means of transmitting reputation are technically sound. There is reason to doubt both of these assumptions, and there is no evidence that these design questions have been given due consideration and resolved - as our process would normally require. At the same time, the process that produced this proposal has at least three traits of processes that have been known to cause problems in the past. This should if nothing else give us pause, and counsel us to proceed with caution. So my recommendation to ASRG (and this document's authors) is as follows: 1. Abandon the effort to publish draft-irtf-asrg-dnsbl as a standards track document, and instead commit to publishing it as an Informational document as an accurate description of existing practice. Be sure to document observed limitations of existing practice. 2. Ask IETF to charter a working group tasked with developing a protocol for communicating email sender reputation. The group can consider DNSBL as a possible solution but should not be bound by a requirement to be compatible with it, or to use DNS at all. Keith _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf