Original text:
the frame.  These frames are explained in more detail in frame- formats. <del> The "Packets" column in frame-types does not form part of the IANA registry; see iana-frames.  This column lists the types of packets that each frame type could appear in, indicated by the following characters: </del>  Initial (packet-initial) Section 4 of QUIC-TLS provides more detail about these restrictions. Note that all frames can appear in 1-RTT packets.  An endpoint MUST treat the receipt of a frame of unknown type as a connection error of type FRAME_ENCODING_ERROR. format and assigned semantics of any fields in the frame. The initial contents of this registry are tabulated in frame-types. <del> Note that the registry does not include the "Packets" column from frame-types. </del>  22.4.

Reviewer comments:
After considering this a little more it seems helpful to bring some of the special handling rules up into the summary. We don't really give up-front treatment of ack-eliciting, probing, and other important distinctions, so an extra column seemed useful. A table of this size just fits in the text format.
I had almost exactly those changes in a previous version. It was a near thing.
That is super helpful, and is the direction I was hoping for!
In Section Frame Types and Formats, there is a very useful summary of frame types by packet type. As a person with a CC and transport protocol interest, it would be really nice to have had a summary table of key properties that included whether each frame type is ack-eliciting; whether transmission is controlled by flow-control; and whether transmission is controlled by congestion-control. Is there any chance we can add an extra column say to this table?
The problem with the table is that it is already essentially the full width available to us. That makes the addition of more information quite difficult. The rules for most of these are simple enough that I'm not sure that the table is the best way to present it. That is: ack-eliciting: all except ACK, PADDING congestion-controlled: all except ACK flow controlled: only STREAM
I wouldn't want to mess-up the table format to include the info. However, it would be really nice to have the info in a compact way close to the table somehow so that readers quickly confirm this. Would a note below the table possibly work, saying just this?

Revised text:
the frame.  These frames are explained in more detail in frame- formats.  <ins> The "Pkts" column in frame-types lists the types of packets that each frame type could appear in, indicated by the following characters: </ins> Initial (packet-initial) Section 4 of QUIC-TLS provides more detail about these restrictions. Note that all frames can appear in 1-RTT packets. <ins> The "Spec" column in frame-types summarizes any special rules governing the processing or generation of the frame type, as indicated by the following characters: Packets containing only frames with this marking are not ack- eliciting; see generating-acks. Packets containing only frames with this marking do not count toward bytes in flight for congestion control purposes; see QUIC- RECOVERY. Packets containing only frames with this marking can be used to probe new network paths during connection migration; see probing. The content of frames with this marking are flow controlled; see flow-control. The "Pkts" and "Spec" columns in frame-types do not form part of the IANA registry; see iana-frames. </ins> An endpoint MUST treat the receipt of a frame of unknown type as a connection error of type FRAME_ENCODING_ERROR. format and assigned semantics of any fields in the frame. The initial contents of this registry are tabulated in frame-types.  <ins> Note that the registry does not include the "Pkts" and "Spec" columns from frame-types. </ins> 22.4.