Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[[e-mail]]

> 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 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf