Original text:
deadlocked if the decoder withholds flow control credit until the instruction is completely received. <del> To avoid these deadlocks, an encoder SHOULD avoid writing an instruction unless sufficient stream and connection flow control credit is available for the entire instruction. </del>  2.1.4. field name might occur for shorter values more quickly or with higher probability than for longer values.  7.1.3. Implementations can also choose to protect sensitive fields by not table are registered in the "HTTP/3 Settings" registry established in HTTP3.  8.2. This document specifies two stream types.  The entries in the

Reviewer comments:
NAME said
I think we can change to SHOULD NOT. I'd rather not be so prescriptive here, since a QPACK implementation might well cut this corner and ignore flow control constraints and rely on higher levels of the stack to ensure the necessary flow control is available? I guess I could be convinced otherwise.
NAME
NAME said
Even though newlines are not really allowed (unescaped) in field values, we can add a note to this effect.
NAME said
Yes, that's why they're not there.
Propose to close with no action then? Or is there a way to reformat the table to include the longer names?
I see a couple options in addition to "close with no change", namely to add a note below the table that the names are abbreviated, or to write out the IANA directives in prose without a table at all. I don't have a particular preference among those three options, though.
We need to come to a decision on this. Since this is from an IESG COMMENT (and not a DISCUSS), the editors can IMO go ahead with their preferred resolution.
NAME said
I agree it's not worth mitigating technically. I question whether it's worth documenting, personally, but it does no harm.
Maybe just a sentence that this mitigation has limits when traversing multiple intermediaries?
That seems like it would strike a reasonable balance.
NAME said
This table appears before the general discussion of indexing. One thought is to add something along the top of the table, like this: ?
Your proposal does improve the clarity of the figure, but I am hoping for more. While it is true that the dedicated sections that discuss indexing appear later in the document, the introductory text alongside the figure uses language such as "smallest absolute index", increases the draining index", and "with an absolute index lower than the draining index" that imply a numerical ordering and directionality of the indices. Interpreting the figure would be easier with the direction of that ordering stated explicitly, as might be done via "Newer Entries (larger index)"/etc..
We need to come to a decision on this. Since this is from an IESG COMMENT (and not a DISCUSS), the editors can IMO go ahead with their preferred resolution.

Revised text:
deadlocked if the decoder withholds flow control credit until the instruction is completely received.  <ins> To avoid these deadlocks, an encoder SHOULD NOT write an instruction unless sufficient stream and connection flow control credit is available for the entire instruction. </ins> 2.1.4. field name might occur for shorter values more quickly or with higher probability than for longer values. <ins> This mitigation is most effective between two endpoints.  If messages are re-encoded by an intermediary without knowledge of which entity constructed a given message, the intermediary could inadvertently merge compression contexts that the original encoder had specifically kept separate. </ins> 7.1.3. Implementations can also choose to protect sensitive fields by not table are registered in the "HTTP/3 Settings" registry established in HTTP3. <ins> For fomatting reasons, the setting names here are abbreviated by removing the 'SETTING_' prefix. </ins> 8.2. This document specifies two stream types.  The entries in the