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