diff --git a/doc/bugs/git-annex-shell_doesn__39__t_honour_Rsync__39__s_bwlimit_option/comment_2_15e06f6db9a14a8217dea25e24ddc23a._comment b/doc/bugs/git-annex-shell_doesn__39__t_honour_Rsync__39__s_bwlimit_option/comment_2_15e06f6db9a14a8217dea25e24ddc23a._comment
new file mode 100644
index 0000000000..8c41b51f00
--- /dev/null
+++ b/doc/bugs/git-annex-shell_doesn__39__t_honour_Rsync__39__s_bwlimit_option/comment_2_15e06f6db9a14a8217dea25e24ddc23a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="guilhem"
+ ip="46.239.117.180"
+ subject="comment 2"
+ date="2013-03-10T03:06:55Z"
+ content="""
+From my tests, Rsync actually seems to honor the bandwidth limit that's in the sender's options. In particular, a dirty hard-coding of the limit in Utility.Rsync.rsyncServerParams (forwarding the option from git-annex-shell to the actuall rsync command, and) did the trick for me.
+
+I know Rsync merely tries to respect bwlimit on average, but for large files it's good enough I think. And for those like me who have a volume quota on their connection, it'd a plus to make git-annex-shell respect that limit. Well of course I could ask my users to use something like trickle, but external commands are more likely to be forgotten than a config option ;-)
+
+I couldn't see where in the code you whitelist the list of safe commands; Did you mean there is already such a thing, or is it empty right now? In any case, my wish doesn't seem to be hard to implement, and I'd be happy to try to provide a patch in the next few days.
+"""]]