On Wed 29/Jan/2014 17:16:56 +0100 IAB Chair wrote: > This is a call for review of "Technical Considerations for Internet > Service Blocking and Filtering" prior to potential approval as an > IAB stream RFC. > > The document is available for inspection here: > https://datatracker.ietf.org/doc/draft-iab-filtering-considerations/ Albeit it purports to keep clear of (un)ethical considerations, the document seems to be oriented toward government-imposed restrictions, recounting how it would be better to move filtering to collaborative endpoints rather than disrupting Internet operation, since bad actors can circumvent filtering anyway. I fully agree, but I think that a general purpose document on this subject might have touched on such points as password management, user identification, and outbound port 25 blocking. Some minor comments, in top-down order: 1. *Introduction*, par 3 As noted in [RFC4084], some Internet service providers impose restrictions on which applications their customers may use and which traffic they allow on their networks. To avoid confusion, I'd s/impose restrictions/perform filtering/, since RFC 4084 says about Firewalled Internet Connectivity: It is distinguished from the models above by the fact that any filtering or blocking services are ultimately performed at customer request, rather than being imposed as service restrictions. Alternatively, that snippet could refer to "Section 3 of [RFC4084]". 2. *Filtering Examples*, par 3 (Web Filtering) The second half of that paragraph is rather lengthy and obscure --the explanation in Section 5 is much clearer. It could be shortened for readability, for example: OLD: To block access to content made accessible via HTTPS, filtering systems thus must either block based on network- and transport-layer headers (IP address and/or port), or else obtain a trust anchor certificate that is trusted by endpoints (and thus act as a man in the middle). These filtering systems often take the form of "portals" or "enterprise proxies." These portals present their own HTTPS certificates that are invalid for any given domain according to normal validation rules, but may still be trusted if the user installs a security exception. (See further discussion in Section 5.) NEW: To block access to content made accessible via HTTPS, filtering systems thus must either block based on network- and transport-layer headers (IP address and/or port), or act as a man in the middle by requiring the user to install security exceptions. The latter filtering systems often take the form of "portals" or "enterprise proxies", presenting their own, dynamically generated HTTPS certificates. (See further discussion in Section 5.) 3.1. *Entities that set blocking policies* Parties that institute blocking policies include governments, enterprises, network operators, application providers, and individual end users. Which of those terms includes Spamhaus? I'd propose to add "reputation trackers". 3.4. *Components used for blocking*, par 1 Broadly speaking, the process of a delivering an Internet service involves three different components: s/a delivering/delivering/ 4.3.5. *Examples*, par 3 s/e-mail/email/ 6. *Conclusion* s/Because it least/Because it is least/ Ale