diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md
index 4885c6f345..73e348ac01 100644
--- a/draft-ietf-quic-tls.md
+++ b/draft-ietf-quic-tls.md
@@ -325,32 +325,8 @@ One important difference between TLS records (used with TCP) and QUIC CRYPTO
 frames is that in QUIC multiple frames may appear in the same QUIC packet as
 long as they are associated with the same packet number space. For instance,
 an endpoint can bundle a Handshake message and an ACK for some Handshake data
-into the same packet.
-
-Some frames are prohibited in different packet number spaces. The rules here
-generalize those of TLS, in that frames associated with establishing the
-connection can usually appear in packets in any packet number space, whereas
-those associated with transferring data can only appear in the application
-data packet number space:
-
-- PADDING, PING, and CRYPTO frames MAY appear in any packet number space.
-
-- CONNECTION_CLOSE frames signaling errors at the QUIC layer (type 0x1c) MAY
-  appear in any packet number space. CONNECTION_CLOSE frames signaling
-  application errors (type 0x1d) MUST only appear in the application data packet
-  number space.
-
-- ACK frames MAY appear in any packet number space, but can only acknowledge
-  packets that appeared in that packet number space.  However, as noted below,
-  0-RTT packets cannot contain ACK frames.
-
-- All other frame types MUST only be sent in the application data packet number
-  space.
-
-Note that it is not possible to send the following frames in 0-RTT packets for
-various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN, PATH_RESPONSE, and
-RETIRE_CONNECTION_ID.  A server MAY treat receipt of these frames in 0-RTT
-packets as a connection error of type PROTOCOL_VIOLATION.
+into the same packet. Some frames are prohibited in different packet number
+spaces; see Section 12.5 of {{QUIC-TRANSPORT}}.
 
 Because packets could be reordered on the wire, QUIC uses the packet type to
 indicate which keys were used to protect a given packet, as shown in
diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md
index ff89247633..da4ef8b29d 100644
--- a/draft-ietf-quic-transport.md
+++ b/draft-ietf-quic-transport.md
@@ -3440,7 +3440,7 @@ ih:
 : Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial or Handshake
   packets.
 
-Section 4 of {{QUIC-TLS}} provides more detail about these restrictions.  Note
+For more detail about these restrictions, see {{frames-and-spaces}}.  Note
 that all frames can appear in 1-RTT packets.  An endpoint MUST treat receipt of
 a frame in a packet type that is not permitted as a connection error of type
 PROTOCOL_VIOLATION.
@@ -3487,6 +3487,33 @@ This rule applies to all current and future QUIC frame types.  An endpoint
 MAY treat the receipt of a frame type that uses a longer encoding than
 necessary as a connection error of type PROTOCOL_VIOLATION.
 
+## Frames and Number Spaces {#frames-and-spaces}
+
+Some frames are prohibited in different packet number spaces. The rules here
+generalize those of TLS, in that frames associated with establishing the
+connection can usually appear in packets in any packet number space, whereas
+those associated with transferring data can only appear in the application
+data packet number space:
+
+- PADDING, PING, and CRYPTO frames MAY appear in any packet number space.
+
+- CONNECTION_CLOSE frames signaling errors at the QUIC layer (type 0x1c) MAY
+  appear in any packet number space. CONNECTION_CLOSE frames signaling
+  application errors (type 0x1d) MUST only appear in the application data packet
+  number space.
+
+- ACK frames MAY appear in any packet number space, but can only acknowledge
+  packets that appeared in that packet number space.  However, as noted below,
+  0-RTT packets cannot contain ACK frames.
+
+- All other frame types MUST only be sent in the application data packet number
+  space.
+
+Note that it is not possible to send the following frames in 0-RTT packets for
+various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN, PATH_RESPONSE, and
+RETIRE_CONNECTION_ID.  A server MAY treat receipt of these frames in 0-RTT
+packets as a connection error of type PROTOCOL_VIOLATION.
+
 # Packetization and Reliability {#packetization}
 
 A sender sends one or more frames in a QUIC packet; see {{frames}}.
@@ -6156,7 +6183,7 @@ Reason Phrase:
   This SHOULD be a UTF-8 encoded string {{!RFC3629}}.
 
 The application-specific variant of CONNECTION_CLOSE (type 0x1d) can only be
-sent using 0-RTT or 1-RTT packets; see Section 4 of {{QUIC-TLS}}.  When an
+sent using 0-RTT or 1-RTT packets; see {{frames-and-spaces}}.  When an
 application wishes to abandon a connection during the handshake, an endpoint
 can send a CONNECTION_CLOSE frame (type 0x1c) with an error code of
 APPLICATION_ERROR in an Initial or a Handshake packet.