>> >> c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect draft-livingood-dns-malwareprotect concerns what is primarily an opt-in service to block known malware sites for end users. Hopefully that is less controversial than the redirect one, but who knows. draft-livingood-dns-redirect was written to do two things. First was to document a relatively long-standing process in a reference-able IETF document where no documentation previously existed. Second was to document the best or least worst way to approach it, if a party was planning to do so. Since that time, I've added a bunch of stuff related to DNSSEC to make clear an incompatibility there. I'm a bit conflicted though about whether to keep it as informational or consider historic. In any case, as noted below, I'm more than happy to consider any text that might improve these document by providing more information on opposing viewpoints, etc. >> descibe these "services" in a much too friendly tone; >> terms like "service" and "benefits for users" are clearly >> abuse of language -- the above IAB statement already indicates Sorry you feel that way. Operators view these as services and describe them as such, so I am simply using that language. As I do my next pass through the documents I will review it for any non-neutral descriptors. Of course, also feel free to email me a list of the ones you think I should consider revising in some manner. >> that similar interference with the DNS causes severe damage >> to user perception and performance. The 2nd draft concerns protection from malware, which is generally assumed to be a service that users opt-into (a la OpenDNS, etc.). Those users who have decided to use such services very likely are much more concerned with malware than the fact that FQDNs associated with malware would be blocked. Again, I'm quite willing to include text you wish to propose to capture alternative viewpoints and criticisms, as that's an important part of such a document IMHO. >> These drafts should clearly spell out the downside of these >> methods and their fundamental nature, being MitM attacks. I'm happy to consider any text you would like to propose, and am quite willing to include specific notes that some in the community consider the techniques MitM attacks, in order to try to capture all viewpoints on the subject. Feel free to send any proposed text to me via email. Regards, Jason _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf