diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md
index 3fbf43fcdd..f6b43ec9b6 100644
--- a/draft-ietf-quic-transport.md
+++ b/draft-ietf-quic-transport.md
@@ -124,9 +124,9 @@ provides:
 
 * Authenticated and encrypted header and payload
 
-QUIC uses UDP as a substrate to avoid requiring changes in legacy client
+QUIC uses UDP as a substrate to avoid requiring changes to legacy client
 operating systems and middleboxes.  QUIC authenticates all of its headers and
-encrypts most of the data it exchanges, including its signaling, to avoid
+encrypts most of the data it exchanges -- including its signaling -- to avoid
 incurring a dependency on middleboxes.
 
 
@@ -383,7 +383,7 @@ data to a peer.
 ~~~
        o
        | Create Stream (Sending)
-       | Create Bidirectional Stream (Receiving)
+       | Remote Creates Bidirectional Stream
        v
    +-------+
    | Ready | Send RESET_STREAM
@@ -651,13 +651,14 @@ upon receipt.
 A STOP_SENDING frame requests that the receiving endpoint send a RESET_STREAM
 frame.  An endpoint that receives a STOP_SENDING frame MUST send a RESET_STREAM
 frame for that stream.  An endpoint SHOULD copy the error code from the
-STOP_SENDING frame, but MAY use any other application error code.  The endpoint
+STOP_SENDING frame, but MAY use any application error code.  The endpoint
 that sends a STOP_SENDING frame can ignore the error code carried in any
 RESET_STREAM frame it receives.
 
 If the STOP_SENDING frame is received on a send stream that is already in the
-"Data Sent" state, a RESET_STREAM frame MAY still be sent in order to cancel
-retransmissions of previously-sent STREAM frames.
+"Data Sent" state, an endpoint which wishes to cease retransmission of
+previously-sent STREAM frames on that stream MUST first send a RESET_STREAM
+frame.
 
 STOP_SENDING SHOULD only be sent for a receive stream that has not been
 reset. STOP_SENDING is most useful for streams in the "Recv" or "Size Known"
@@ -834,7 +835,7 @@ commitment.
 ## Controlling Concurrency {#controlling-concurrency}
 
 An endpoint limits the cumulative number of incoming streams a peer can open.
-Only steams with a stream id less than
+Only streams with a stream id less than
 (max_stream * 4 + initial_stream_id_for_type) can be opened.  Initial limits
 are set in the transport parameters (see {{transport-parameter-definitions}})
 and subsequently limits are advertised using MAX_STREAMS frames
@@ -882,13 +883,13 @@ selected by endpoints; each endpoint selects the connection IDs that its peer
 uses.
 
 The primary function of a connection ID is to ensure that changes in addressing
-at lower protocol layers (UDP, IP, and below) don't cause packets for a QUIC
+at lower protocol layers (UDP, IP) don't cause packets for a QUIC
 connection to be delivered to the wrong endpoint.  Each endpoint selects
 connection IDs using an implementation-specific (and perhaps
 deployment-specific) method which will allow packets with that connection ID to
 be routed back to the endpoint and identified by the endpoint upon receipt.
 
-Connection IDs MUST NOT contain any information that can be used to correlate
+Connection IDs MUST NOT contain any information that can be used by to correlate
 them with other connection IDs for the same connection.  As a trivial example,
 this means the same connection ID MUST NOT be issued more than once on the same
 connection.
@@ -1190,8 +1191,9 @@ described in {{QUIC-TLS}}; a different QUIC version number could indicate that a
 different cryptographic handshake protocol is in use.
 
 QUIC provides reliable, ordered delivery of the cryptographic handshake
-data. QUIC packet protection ensures confidentiality and integrity protection
-that meets the requirements of the cryptographic handshake protocol:
+data. QUIC packet protection is used to encrypt as much of the handshake
+protocol as possible. The cryptographic handshake MUST provide the following
+properties:
 
 * authenticated key exchange, where
 
@@ -1337,7 +1339,8 @@ Source Connection IDs during the handshake.
 On first receiving an Initial or Retry packet from the server, the client uses
 the Source Connection ID supplied by the server as the Destination Connection ID
 for subsequent packets.  That means that a client might change the Destination
-Connection ID twice during connection establishment.  Once a client has received
+Connection ID twice during connection establishment, once in response to a
+Retry and once in response to the server's Initial. Once a client has received
 an Initial packet from the server, it MUST discard any packet it receives with a
 different Source Connection ID.
 
@@ -1377,7 +1380,8 @@ of duplicate transport parameters as a connection error of type
 TRANSPORT_PARAMETER_ERROR.
 
 A server MUST include the original_connection_id transport parameter
-({{transport-parameter-definitions}}) if it sent a Retry packet.
+({{transport-parameter-definitions}}) if it sent a Retry packet, in
+order to enable validation of the Retry, as described in {{packet-retry}}.
 
 
 ### Values of Transport Parameters for 0-RTT {#zerortt-parameters}
@@ -1398,12 +1402,17 @@ A server MAY accept 0-RTT and subsequently provide different values for
 transport parameters for use in the new connection.  If 0-RTT data is accepted
 by the server, the server MUST NOT reduce any limits or alter any values that
 might be violated by the client with its 0-RTT data.  In particular, a server
-that accepts 0-RTT data MUST NOT set values for initial_max_data,
-initial_max_stream_data_bidi_local, initial_max_stream_data_bidi_remote,
-initial_max_stream_data_uni, initial_max_streams_bidi, or
-initial_max_streams_uni ({{transport-parameter-definitions}}) that are smaller
+that accepts 0-RTT data MUST NOT set values for the following parameters
+({{transport-parameter-definitions}}) that are smaller
 than the remembered value of those parameters.
 
+* initial_max_data
+* initial_max_stream_data_bidi_local
+* initial_max_stream_data_bidi_remote
+* initial_max_stream_data_uni
+* initial_max_streams_bidi
+* initial_max_streams_uni
+
 Omitting or setting a zero value for certain transport parameters can result in
 0-RTT data being enabled, but not usable.  The applicable subset of transport
 parameters that permit sending of application data SHOULD be set to non-zero
@@ -1415,8 +1424,8 @@ The value of the server's previous preferred_address MUST NOT be used when
 establishing a new connection; rather, the client should wait to observe the
 server's new preferred_address value in the handshake.
 
-A server MUST reject 0-RTT data or even abort a handshake if the implied values
-for transport parameters cannot be supported.
+A server MUST either reject 0-RTT data or abort a handshake if the implied
+values for transport parameters cannot be supported.
 
 
 ### New Transport Parameters