diff --git a/doc/spec/proposals/141-jit-sd-downloads.txt b/doc/spec/proposals/141-jit-sd-downloads.txt
index b6d27c86e8..9241089d5b 100644
--- a/doc/spec/proposals/141-jit-sd-downloads.txt
+++ b/doc/spec/proposals/141-jit-sd-downloads.txt
@@ -119,28 +119,19 @@ Status: Draft
   to the "r", "s", and "v" lines that already exist.  This line
   will convey weight information to clients.
 
-   "w Exit=41 Guard=94 Middle=543 ..."
+   "w Bandwidth=193671"
 
-  It starts with the letter w and then contains any number of Key=Value
-  pairs.  Values will be non-negative integers.  Clients will pick
-  routers with a propability proportional to the number for the intended
-  purpose.
+  The bandwidth number is the lesser of observed bandwidth and bandwidth
+  rate limit from the server descriptor that the "r" line referenced by
+  digest (1st and 3rd field of the bandwidth line in the descriptor).
 
-  Clients MUST accept sums of all weights for a given purpose over all
-  routers in a consensus up to UINT64_max.
-
-  [XXX how do we arrive at a consensus weight?
-    option a) Perhaps the vote could contain the node's bandwidth, and
-              this could be used to calculate the weights?  It's
-              necessary that the consensus remain a deterministic
-              function of the votes.
-    option b) Every voter assigns weights for each of the purposes
-              (Exit, Guard, ..) so that their total sum is some constant
-              X.  When building a consensus we take the median for each
-              purpose for each router.
-
-    Option a has the disadvantage that if we want to tweak the weighting
-    we have to make a new consensus-method]
+  The bandwidth item is added as another item in the router tuple
+  described in dir-spec section 3.4:
+   | * Two router entries are "the same" if they have the same
+   | <descriptor digest, published time, nickname, IP, ports> tuple.
+   | We choose the tuple for a given router as whichever tuple appears
+   | for that router in the most votes.  We break ties in favor of
+   | the more recently published.
 
 3.2 Fetching descriptors on demand
 
@@ -198,14 +189,15 @@ Status: Draft
 
 3.3 Protocol versions
 
-  [XXX: find out where we need "opt protocols Link 1 2 Circuit 1"
-  information described in 2.3 above.  If we need it, it might have
-  to go into the consensus document.]
+  Server descriptors contain optional information of supported
+  link-level and circuit-level protocols in the form of
+  "opt protocols Link 1 2 Circuit 1".  These are not currently needed
+  and will probably eventually move into the "v" (version) line in
+  the consensus.  This proposal does not deal with them.
 
-  [XXX: Similarly find out where we need the version number of a
-  remote tor server.  This information is in the consensus, but
-  maybe we use it in some place where having it signed by the
-  server in question is really important?]
+  Similarly a server descriptor contains the version number of
+  a Tor node.  This information is already present in the consensus
+  and is thus available to all clients immediately.
 
 3.4 Exit selection