diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md
index 138eb269ef..a20446611e 100644
--- a/draft-ietf-quic-http.md
+++ b/draft-ietf-quic-http.md
@@ -422,7 +422,7 @@ PUSH_PROMISE frames are not part of the response; see {{server-push}} for more
 details.
 
 Frames of unknown types ({{extensions}}), including reserved frames
-({{frame-grease}}) MAY be sent on a request or push stream before, after, or
+({{frame-reserved}}) MAY be sent on a request or push stream before, after, or
 interleaved with other frames described in this section.
 
 The HEADERS and PUSH_PROMISE frames might reference updates to the QPACK dynamic
@@ -890,7 +890,7 @@ A sender can close or reset a unidirectional stream unless otherwise specified.
 A receiver MUST tolerate unidirectional streams being closed or reset prior to
 the reception of the unidirectional stream header.
 
-###  Control Streams
+### Control Streams
 
 A control stream is indicated by a stream type of `0x00`.  Data on this stream
 consists of HTTP/3 frames, as defined in {{frames}}.
@@ -974,6 +974,7 @@ comparison between HTTP/2 and HTTP/3 frames is provided in {{h2-frames}}.
 | GOAWAY         | Yes            | No             | No          | {{frame-goaway}}         |
 | MAX_PUSH_ID    | Yes            | No             | No          | {{frame-max-push-id}}    |
 | DUPLICATE_PUSH | No             | Yes            | No          | {{frame-duplicate-push}} |
+| Reserved       | Yes            | Yes            | Yes         | {{frame-reserved}        |
 {: #stream-frame-mapping title="HTTP/3 frames and stream type overview"}
 
 Certain frames can only occur as the first frame of a particular stream type;
@@ -1373,18 +1374,22 @@ uses a Push ID that they have since consumed and discarded are forced to ignore
 the DUPLICATE_PUSH.
 
 
-### Reserved Frame Types {#frame-grease}
+### Reserved Frame Types {#frame-reserved}
 
 Frame types of the format `0x1f * N + 0x21` for integer values of N are reserved
 to exercise the requirement that unknown types be ignored ({{extensions}}).
-These frames have no semantics, and can be sent when application-layer padding
-is desired. They MAY also be sent on connections where no data is currently
-being transferred. Endpoints MUST NOT consider these frames to have any meaning
-upon receipt.
+These frames have no semantics, and can be sent on any open stream when
+application-layer padding is desired. They MAY also be sent on connections where
+no data is currently being transferred. Endpoints MUST NOT consider these frames
+to have any meaning upon receipt.
 
 The payload and length of the frames are selected in any manner the
 implementation chooses.
 
+Frame types which were used in HTTP/2 where there is no corresponding HTTP/3
+frame have also been reserved ({{iana-frames}}).  These frame types MUST NOT be
+sent, and receipt MAY be treated as an error of type HTTP_UNEXPECTED_FRAME.
+
 
 # Error Handling {#errors}
 
@@ -1486,7 +1491,10 @@ Implementations MUST ignore unknown or unsupported values in all extensible
 protocol elements.  Implementations MUST discard frames and unidirectional
 streams that have unknown or unsupported types.  This means that any of these
 extension points can be safely used by extensions without prior arrangement or
-negotiation.
+negotiation.  However, where a known frame type is required to be in a specific
+location, such as the SETTINGS frame as the first frame of the control stream
+(see {{control-streams}}), an unknown frame type does not satisfy that
+requirement and SHOULD be treated as an error.
 
 Extensions that could change the semantics of existing protocol components MUST
 be negotiated before being used.  For example, an extension that changes the
@@ -1516,7 +1524,7 @@ security considerations of {{!ALTSVC}} also apply.
 Where HTTP/2 employs PADDING frames and Padding fields in other frames to make a
 connection more resistant to traffic analysis, HTTP/3 can either rely on
 transport-layer padding or employ the reserved frame and stream types discussed
-in {{frame-grease}} and {{stream-grease}}.  These methods of padding produce
+in {{frame-reserved}} and {{stream-grease}}.  These methods of padding produce
 different results in terms of the granularity of padding, the effect of packet
 loss and recovery, and how an implementation might control padding.