Change:
stream. When processing header blocks, the decoder expects the Required <del> Insert Count to exactly match the value defined in blocked-streams. If it encounters a smaller value than expected, it MUST treat this as a connection error of type QPACK_DECOMPRESSION_FAILED; see invalid- references.  If it encounters a larger value than expected, it MAY treat this as a connection error of type QPACK_DECOMPRESSION_FAILED. </del> <ins> Insert Count to equal the lowest possible value for the Insert Count with which the header block can be decoded, as prescribed in blocked- streams.  If it encounters a Required Insert Count smaller than expected, it MUST treat this as a connection error of type QPACK_DECOMPRESSION_FAILED; see invalid-references.  If it encounters a Required Insert Count larger than expected, it MAY treat this as a connection error of type QPACK_DECOMPRESSION_FAILED. </ins> 2.2.2.

Discussion:
Restating the definition of Required Insert Count in the first sentence is probably not necessary. However, I believe rewording the second and the third sentences is an improvement.
If an encoder produces a Required Insert Count that is invalid, what can a decoder do? The encoder could provide a value that is too high. In the case where the value is high, but the number of entries is already acknowledged, this is probably harmless. However, the decoder might block unnecessarily, if the values were not already present and the encoder references none of those entries or only references lower-indexed entries than it declared. This is a performance problem up until the point where the encoder hasn't provided the "required" entries and finds no reason to do so, at which point the performance bug could be come a deadlock. The encoder could provide a value that is too low. The decoder might then reasonably reject an encoding, but some will not. If the value is only too low and the entry is present in the dynamic table, some encoders will happily pull the value from the table and use it. Those decoders will only generate an error if the entry isn't there yet. I think that it would be better for the protocol if a decoder were able to generate an error if the maximum index referred to in a header block did not exactly match the Required Insert Count.
The "finds no reason to do so" is a functional, not performance, bug in the encoder. As for performance, that's why there is the setting. I thought there was verbiage to that effect already, but I don't see it in the .
Alan found this in . It's a little obtuse though.
I am assuming that you are referring specifically to this paragraph?
I interpreted this as saying that the encoder produced a RIC for entries that don't exist in the table yet and perhaps never will. The bug is still producing a RIC that isn't referenced in the encoded header block.
I feel like the draft explicitly says this is an error. Here's the current text: Which part is obtuse? Should I replace 'URL value defined in Section 2.1.3.' and '...smaller/larger than expected' with a restatement of the expected values? I'm pretty sure it used to say that and we changed it to this.

Or would moving it to another section make it easier to find? Regarding whether this is a functional or performance bug, I expect many implementations won't parse the header block until the RIC is met, so the encoder can cause the decoder to block a stream indefinitely. This can lead to other poor compression performance effects, but I don't think it can cause an actual deadlock on any request other than the one with the bad RIC, which is the encoder's fault anyways. Maybe a security consideration recommending timeouts for this case?
Which value matches the Required Insert Count? I think that you mean that the Required Insert Count value and the lowest index found in the block have to be equal. If the lowest index found is smaller than RIC, then MUST; else if lowest > RIC, then MAY. Does that help clarify?
I think it already says the right thing, but I agree that "the value defined in Section 2.1.3 is a bit opaque. IIRC, you're right that it was the result of a compromise. It would probably be clearest to have another defined term, but we have a lot of those already.
This is not only a performance problem or a potential deadlock. If the encoder sends an unnecessarily large Required Insert Count but does not consider the stream blocked if the Known Insert Count is at least as large as the actual Required Insert Count, and the decoder does not start decoding until the Known Insert Count reaches the Required Insert Count received in the header block prefix (therefore it does not realize that the stream is in fact not blocked), then the encoder and the decoder might have a different idea about the number of blocked streams. This might result in the decoder closing the connection due to SETTINGSQPACKBLOCKED_STREAMS violation. Of course is the encoder uses the same incorrect value for sending as Required Insert Count and for bookkeeping of blocked streams then this problem does not arise.
Moving it to another section, like to 2.1.3 (within the encoder section), might help the text flow better. However, since this paragraph is discussing requirements on the decoder, the subsection where it is right now is probably the most suitable one.