>"Not wanting to be recruited into a botnet" is another such consideration. >Paul and Vernon invented a useful tool to help address it, and I'm >in favor of documenting it.
I would really prefer that the IETF not embarrass itself with a rerun of the NAT fiasco, in which TCP/IP purists yelled and screamed and insisted that NAT was evil, while in the real world it solved (still solves) real problems, and everyone implemented it in various not very transparent or compatible ways. RPZ is ugly but it solves serious real world problems, and it's going to be used all over the world regardless of what we do. Just this week I heard from a friend at a largish company that one of their suppliers got hacked with the trendy new malware that hides in web page images. Without RPZ, approximately all of their Windows users would have been infected, with RPZ none of them were. If we want to offer advice and perhaps technical twiddles on how to deploy RPZ to minimize surprises and make it easy to find and fix mistakes, that would be swell. Insisting that it's stupid and wrong confirms the not ill-founded impression that dnsop is out of touch with the real world. So, yes, we should adopt this draft. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
