> Sadly, I have to agree with Keith. While these lists are a > fact of life today, and I would favor an informational document > or document that simply describes how they work and the issues > they raise, standardizing them and formally recommending their > use is not desirable at least without some major changes in our > email model and standards for what gets addresses onto --and, > more important, off of-- those lists. Such a criticism might be a sensible response to a document that defines an actual whitelisting or blacklisting service. But that's not what this document does. Rather, this document defines vaarious formats for storing such information in the DNS and procedures for querying that data. Specification of actual services based on these formats and procedures is left for later specifications. Standardizing these formats and procedures is important for at least two reasons: (1) Without a specification nailing down these details there can be (and in practice have been) interoperability problems between various implementations and (2) Without something describing how to structure and operate these systems they can, independent of the actual list content, create serious operational problems. Now, I am of course aware of the line of reasoning that says we should not publish specifications for things that can potentially be abused. I'm sorry, but if we take a candid look at how this strategy has played out with other technologies ranging from MIME downgrading to NAT to Bonjour, I think the record is fairly clear: We're much better off specifying things while calling out the dangers of their use than we are when we all run off out our respective corners and pout about the sad state of the world. Assuming that the document does in fact define sensible formats that can be operated at Internet scale (I think it does but am willing to be shown otherwise by those with more expertise in large-scale DNS operations than I have) and does not preclude operating a reliable and accountable service (again, I think it does but I am willing to be proved wrong with specific examples), I support publication of this specification. Ned _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf