Hi Alessandro, Thanks for your comments. I have one question below. On 1/30/14 10:52 AM, "Alessandro Vesely" <vesely@xxxxxxx> wrote: >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 Could you expand a bit about what you feel is missing as regards to password management and user identification? Thanks, Alissa >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