I might be a good idea to filter out multicast space, though. That's 224.0.0.0/4. And other "special use" spaces:
Your argument is that we can filter these without hurting the Tor network, and generally speaking you are probably right. However, we should require POSITIVE reasons to filter, not NEGATIVE reasons not to filter. There is a subtle difference. Tor should adopt the most liberal policy that avoids making the general population angry, not the most conservative policy that allows essential functionality to continue.
Both of your arguments are biased by a very different view then that of a system administrator. There are two target audiences here -- anonymous users and server administrators. The policy choices which are ideal for one group are probably not ideal for the other.
Once apon a time systems shipped with all services publically visible and no firewalls, because if there was no known exploits (positive reasons to filter), then they may as well be enabled. That was convenient from a user's view. However as we all know by now, that turned out to be bad from a server administrators point of view.
Consider you want to entice system admin A to host a tor server. Sure, you could tell him that this is a cool funky 90's retro service which will proxy basically everything to everywhere unless he figures out how to limit it down to reduce the blacklisting mail, server attacks, and usenet spam reports he gets. Although as an administrator I prefer to see systems that come online with minimal necessary functionality and then let you enable things from there as you become comfortable with them.
This default policy choice doesn't have to be set in stone. As tor becomes more stable and abuse-prone services (like google's usenet proxy) figure out how to deal with anonymous access, then I suspect the default policy can become less restrictive without causing more frustration to a server administrator.
Valient
Attachment:
signature.asc
Description: OpenPGP digital signature