[tor-bugs] #4562 [Pluggable transport]: Write a pluggable transport deployment roadmap

[Tor Bug Tracker & Wiki]

#4562: Write a pluggable transport deployment roadmap
---------------------------------+------------------------------------------
 Reporter:  karsten              |          Owner:  asn                      
     Type:  project              |         Status:  needs_revision           
 Priority:  normal               |      Milestone:  Sponsor G: March 31, 2012
Component:  Pluggable transport  |        Version:                           
 Keywords:                       |         Parent:                           
   Points:                       |   Actualpoints:                           
---------------------------------+------------------------------------------

Comment(by karsten):

 Replying to [comment:7 asn]:
 > Replying to [comment:4 karsten]:
 > >  - In Section 2.1, how will BridgeDB distribute obfuscated bridge
 addresses?  [...]
 > So, I had in mind that initially we would just give out a couple of
 obfs2 addresses along with the usual bridge addresses, and then we would
 progress to a design where the user would be able to query bridgedb for
 specific transports and whatnot.

 Want to add a sentence about that plan to Section 2.2?  Or is that too
 much detail?

 > >  - Sections 2.2 and 2.4 talk about a future that is farther away than
 2.1 and 2.3.  Would it make sense to have Section 2 talk about the future
 in 3--6 months and a new Section 3 talk about the future after that?  If
 not, feel free to ignore this suggestion.
 > Hm, I'm not sure how to give out timeframes. Is it development
 timeframe? Or deployment timeframe? I'll have to think a bit about this. I
 hope to do it tomorrow.

 I guess deployment timeframe, given that this is a deployment roadmap.
 Staying vague is fine, but maybe a hint that statistics in 2.3 will take
 us longer to deploy than NAT punching in 2.4 might be useful.

 > >  - In Section 3 you talk about updating obfsproxy on the server side.
 Are there any plans to have an Obfsproxy Bridge Bundle of some sort?  Or
 will the Tor Bridge Bundle contain obfsproxy by default?
 > Ha! Very good question. I added a subsection to the `User Workflow`
 section for this.
 >
 > My idea is that in the future (when obfsproxy is mature enough) the Tor
 Bridge Bundle will contain obfsproxy by default. No one wants to be the
 operator of a trivially blockable bridge. If you think this is not a good
 idea, I can remove it from the document.

 Sounds like a fine idea to me.  But I'm in no way involved in building
 packages, so don't count on my opinion here.  Just raising the issue.

 > >  - Instead of hacking the bibliography with custom `\bibitem`, please
 consider using footnotes for URLs.
 > Good idea. Done.

 I tweaked the footnotes a bit and made a set of other small changes.  See
 the attached Git patches.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4562#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online