On Sun, Feb 8, 2015 at 1:57 AM, Nick Mathewson nickm@torproject.org wrote:
any time soon? Other suggestions would be welcome.
Everything should have a set of applicable status so parties know, possibly a pinger, in particular if the goal is to keep certain things moving along. Even if you have to use RT/trac to track them or work consistent header onto the git file, etc.
Finally: if you've sent something to tor-dev or to me that should have a proposal number, but doesn't have one yet, please ping me again to remind me!
There are probably tickets out there being worked by parties that function as proposals but happen not to be filed as numbered git proposals. Maybe review the process between trac/git there.
144 Increase the diversity of circuits by detecting nodes belonging the same provider
This is a version of the good idea, "Let's do routing in a way that tries to keep from routing traffic through the same provider too much!" There are complex issues here that the proposal doesn't completely address, but I think it might be a fine idea for somebody to see how much more we know now than we did in 2008, particularly in light of the relevant paper(s) by Matt Edmann and Paul Syverson. (5/2011)
Similar to geoip data, there may be not just IP-to-AS data available in monthly updates, but AS/BGP-path data from the network side that could be included in tor. Consider making a visit to the next NANOG, you may find insight/partners. ie: If two or more nodes within the same AS, or along the same route-path to the tier-1's are shown to not be beneficial to tor, that data would be needed to exclude that situation. Lots of other hypothesis/analysis could be performed. http://en.wikipedia.org/wiki/Tier_1_network http://en.wikipedia.org/wiki/Internet_backbone http://en.wikipedia.org/wiki/Peering