[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #4562 [Pluggable transport]: Write a pluggable transport deployment roadmap
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs