diff --git a/Client-server-discovery-lifecycle.md b/Client-server-discovery-lifecycle.md
index a885449..8b53a8c 100644
--- a/Client-server-discovery-lifecycle.md
+++ b/Client-server-discovery-lifecycle.md
@@ -13,6 +13,12 @@ How should the [server](https://github.com/sbt/sbt/wiki/Client-server-split) be
 * Potentially controversial, but based on experience: operating system lockfile functionality tends to be platform-specific and flaky (e.g. not working on NFS/AFS, not working between threads, stuff like that), so avoid if possible. This is likely a main question (whether to use FileLock).
 * There are more robust platform-specific solutions available, such as D-Bus on Linux, COM or window-based mechanisms on Windows, and launchd on Mac. These are likely a total pain in the ass to use from the JVM, though. Is there any sane-from-JVM way to do a reliable named lock?
 
+## Concerns (possibly newly discovered)
+
+1. Passing sys.props down from forked process to the server.  Things like:
+   `-Dhttp.proxyHost`
+   `-Dsbt.version`
+
 ## Proposal 1: active.properties
 
 This proposal is intended to "self-heal" and work in practice without asking users to kill processes or delete lockfiles - but nobody will call it elegant. The general idea is that a server suicides if the file pointing to that server is overwritten or deleted.