[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #4960 [Tor Relay]: Investigate NAT-piercing approaches for relays and bridges

#4960: Investigate NAT-piercing approaches for relays and bridges
-----------------------+----------------------------------------------------
 Reporter:  karsten    |          Owner:  ioerror                
     Type:  project    |         Status:  new                    
 Priority:  normal     |      Milestone:  Sponsor F: July 1, 2012
Component:  Tor Relay  |        Version:                         
 Keywords:             |         Parent:                         
   Points:             |   Actualpoints:                         
-----------------------+----------------------------------------------------

Comment(by intrigeri):

 Replying to [comment:4 ioerror]:
 > I've uploaded a draft paper that discusses these issues - if anyone has
 feedback, I'd be happy to incorporate it into the final document.

 Being a non-native speaker, I'm shy on ''potential'' spelling typos, but
 let's give it a try anyway:

 * s/reducable/reducible/
 * s/programatic/programmatic/
 * in "monitoring of the third party may reveal every bridge that wishes it
 were reachable", it's not clear that "it" refers to the bridge itself. I
 suggest s/it were/to be/
 * I like section 3. Quite clearly shows most of the anonymity/privacy
 arguments against "trusted" 3rd-party -based solutions migrate gracefully
 to the reachability problem.
 "the UPnP forum managed standard UPnP" is a bit unclear for me. I
 ''think'' I understand it on second read, but it's unclear still.
 * 4.1 lands in a bit brutally. I suggest creating "4.1 Current state of
 NAT traversal protocols in the Tor ecosystem", with a few introduction
 word, and moving 4.1->4.1.1 + 4.2->4.1.2.
 * s/requsite/requisite/
 * in "and manually configure the required port forwarding correctly", I'm
 not sure what value is added by "correctly", and it looks to me it could
 be misunderstood.
 * s/might might/might
 * "as users will have to positively affirm their desire to enable such a
 feature" --> it's not clear to me how they will have to do this.
 * s/should be sent the the/should be sent to the/
 * s/signifigant/significant/

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4960#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs