7 files changed, 57 insertions, 7 deletions
diff --git a/proposals/339-udp-over-tor.md b/proposals/339-udp-over-tor.md
index 12de0c6..e5235d1 100644
--- a/proposals/339-udp-over-tor.md
+++ b/proposals/339-udp-over-tor.md
@@ -11,7 +11,7 @@ Status: Accepted
 Tor currently only supports delivering two kinds of traffic to the
 internet: TCP data streams, and a certain limited subset of DNS
 requests. This proposal describes a plan to extend the Tor protocol so
-that exit relays can also relay UDP traffic to the network?.
+that exit relays can also relay UDP traffic to the network.
 
 Why would we want to do this?  There are important protocols that use
 UDP, and in order to support users that rely on these protocols, we'll
diff --git a/proposals/340-packed-and-fragmented.md b/proposals/340-packed-and-fragmented.md
index 2407f99..cd98cfd 100644
--- a/proposals/340-packed-and-fragmented.md
+++ b/proposals/340-packed-and-fragmented.md
@@ -269,8 +269,23 @@ conflux bundle.
 
 ### An exception for `DATA`.
 
-Data messages may not be fragmented.  (There is never a reason to do
-this.)
+Data messages may not be fragmented. When packing data into a cell containing
+other messages is desired, the application can instead construct a DATA message
+of an appropriate size to fit into the remaining space.
+
+While relaxing this could simplify the implementation of opportunistic packing
+somewhat (by allowing code that constructs `DATA` messages not to have to know
+about packing or fragmentation), doing so would have several downsides.
+
+First, on the receiver side a naive implementation that receives the first cell
+of a fragmented `DATA` message would not be able to pass the data in that
+fragment on to the application until the remaining cells of that message are
+received. An optimized implementation might choose to do so, but that
+complexity seems worse than the complexity we'd be avoiding by allowing `DATA`
+fragmentation in the first place.
+
+Second, as with any sort of flexibility permitted to implementations, allowing
+flexibility here adds opportunities for fingerprinting and covert channels.
 
 ### Extending message-length maxima
 
@@ -286,6 +301,32 @@ Any increase in maximum length for any other message type requires a new
 EXTEND2 messages to be 2000 bytes long, we need to add a new proposal
 saying so, and reserving a new subprotocol version.)
 
+### `SENDME` window accounting
+
+`SENDME` windows count relay *cells* rather than relay *messages*.
+
+A cell counts towards the circuit's `SENDME` window if it contains any part of
+any message that would normally count towards `SENDME` windows (currently only
+`DATA`).
+
+A cell counts towards the `SENDME` window of every stream that it contains
+part of a message for, whose command counts towards `SENDME` windows.
+
+Examples:
+
+* A cell containing a `SENDME` message and a `RESOLVE` message currently
+  wouldn't count towards any windows, since neither of those commands currently
+  counts towards windows.
+* A cell containing a `SENDME` message and a `DATA` message would count towards
+  the circuit window and the `DATA` message's stream's window.
+* A cell containing two `DATA` messages, for different streams, would count
+  towards the circuit-level window and both stream-level windows.
+* A cell containing two `DATA` messages for the *same* stream counts
+  *once* towards the circuit-level and stream-level windows.
+* If `DATAGRAM` messages (proposal 339) are implemented, and count towards
+  windows, then every cell containing a fragment of a `DATAGRAM` message counts
+  towards windows.
+
 # Appendix: Example cells
 
 Here is an example of the simplest case: one message, sent in one relay cell:
diff --git a/spec/SUMMARY.md b/spec/SUMMARY.md
index ade9586..70fa46a 100644
--- a/spec/SUMMARY.md
+++ b/spec/SUMMARY.md
@@ -127,7 +127,7 @@
   - [Appendix F: Hidden service directory format \[HIDSERVDIR-FORMAT\]](./rend-spec/fs-contents.md)
   - [Appendix G: Managing authorized client data \[CLIENT-AUTH-MGMT\]](./rend-spec/client-authorization.md)
   - [Appendix F: Two methods for managing revision counters.](./rend-spec/revision-counter-mgt.md)
-  - [Appendix G: Text vectors](./rend-spec/text-vectors.md)
+  - [Appendix G: Test vectors](./rend-spec/test-vectors.md)
 - [`Proof of Work for onion service introduction`](./hspow-spec/index.md)
   - [Motivation](./hspow-spec/motivation.md)
   - [Common protocol](./hspow-spec/common-protocol.md)
diff --git a/spec/cert-spec.md b/spec/cert-spec.md
index 873c258..98aeffa 100644
--- a/spec/cert-spec.md
+++ b/spec/cert-spec.md
@@ -57,7 +57,7 @@ These representation for this certificate is:
 | - `ExtType`      | 1    | [Type of extension](#list-ext-types)|
 | - `ExtFlags`     | 1    | Control interpretation of extension |
 | - `ExtData`      | `ExtLen` | Encoded extension body          |
-| SIGNATURE        | 64   | Signature of all previous fields    |
+| `SIGNATURE`      | 64   | Signature of all previous fields    |
 
 
 The `VERSION` field holds the value `[01]`.
diff --git a/spec/rend-spec/encrypting-user-data.md b/spec/rend-spec/encrypting-user-data.md
index 460f71e..fdf1a30 100644
--- a/spec/rend-spec/encrypting-user-data.md
+++ b/spec/rend-spec/encrypting-user-data.md
@@ -10,3 +10,10 @@ Tor relay encryption protocol, applying encryption with these keys
 before other encryption, and decrypting with these keys before other
 decryption. The client encrypts with Kf and decrypts with Kb; the
 service host does the opposite.
+
+As mentioned
+[previously](./introduction-protocol.md#INTRO-HANDSHAKE-REQS),
+these keys are used the same as for
+[regular relay cell encryption](../tor-spec/routing-relay-cells.md),
+except that instead of using AES-128 and SHA1,
+both parties use AES-256 and SHA3-256.
diff --git a/spec/rend-spec/introduction-protocol.md b/spec/rend-spec/introduction-protocol.md
index 43c5638..0181dd2 100644
--- a/spec/rend-spec/introduction-protocol.md
+++ b/spec/rend-spec/introduction-protocol.md
@@ -696,7 +696,9 @@ HANDSHAKE_INFO element (see \[JOIN_REND\]).
 The hidden service host now also knows the keys generated by the
 handshake, which it will use to encrypt and authenticate data
 end-to-end between the client and the server. These keys are as
-computed in tor-spec.txt section 5.1.4, except that instead of using
+computed with the
+[ntor handshake](../tor-spec/create-created-cells.html#ntor),
+except that instead of using
 AES-128 and SHA1 for this hop, we use AES-256 and SHA3-256.
 
 <a id="rend-spec-v3.txt-3.4"></a>
diff --git a/spec/rend-spec/text-vectors.md b/spec/rend-spec/test-vectors.md
index eadaee2..d77049e 100644
--- a/spec/rend-spec/text-vectors.md
+++ b/spec/rend-spec/test-vectors.md
@@ -1,6 +1,6 @@
 <a id="rend-spec-v3.txt-G"></a>
 
-# Appendix G: Text vectors
+# Appendix G: Test vectors
 
 G.1. Test vectors for hs-ntor / NTOR-WITH-EXTRA-DATA