Change:
terms of the granularity of padding, how padding is arranged in relation to the information that is being protected, whether padding is applied in the case of packet loss, and how an implementation <del> might control padding.  Redundant padding could even be counterproductive. </del> <ins> might control padding. Reserved stream types can be used to give the appearance of sending traffic even when the connection is idle.  Because HTTP traffic often occurs in bursts, apparent traffic can be used to obscure the timing or duration of such bursts, even to the point of appearing to send a constant stream of data.  However, as such traffic is still flow controlled by the receiver, a failure to promptly drain such streams and provide additional flow control credit can limit the sender's ability to send real traffic. </ins> To mitigate attacks that rely on compression, disabling or limiting compression might be preferable to padding as a countermeasure. Use of padding can result in less protection than might seem <del> immediately obvious.  At best, padding only makes it more difficult for an attacker to infer length information by increasing the number of frames an attacker has to observe.  Incorrectly implemented padding schemes can be easily defeated.  In particular, randomized padding with a predictable distribution provides very little protection; similarly, padding payloads to a fixed size exposes information as payload sizes cross the fixed-sized boundary, which could be possible if an attacker can control plaintext. </del> <ins> immediately obvious.  Redundant padding could even be counterproductive.  At best, padding only makes it more difficult for an attacker to infer length information by increasing the number of frames an attacker has to observe.  Incorrectly implemented padding schemes can be easily defeated.  In particular, randomized padding with a predictable distribution provides very little protection; similarly, padding payloads to a fixed size exposes information as payload sizes cross the fixed-sized boundary, which could be possible if an attacker can control plaintext. </ins> 10.8.

Discussion:
Section 6.2.3: URL These streams have no semantics, and can be sent when application-layer padding is desired. So although a bit unclear I assume the intention here is that one can grab the next available unidirectional stream, send the stream type with a reserved value. After that that endpoint may send arbitrary data at any time while the connection lasts and close it down. I think that could be slightly more explained. What is the cause of this issue is the "Application-layer padding". So I assume that an HTTP/3 implementation could have certain API to request this padding and what behavior it has. However, can this be anything other than generally padding out the QUIC connection. I think from this level it might be hard to have any more detailed control over where the padding data goes. The QUIC scheduler will do what it is programmed to do when it has multiple streams to send and split that into different packets in an implementation dependent fashion. So I wonder what impression people get of this padding feature? It appears hard to use for privacy preserving features as that needs to more consistently ensure that an outside observer can't detect patterns. So it will basically be for keep-alive and consuming more bits, possibly to probe if the application can take the step to the next quality level. So I would think the properties of this should be slightly more explained to not give false hopes.
HTTP traffic patterns can be quite bursty with a lot of cessation. The possible privacy preserving feature comes from an endpoint that can continue to drive application traffic over some time window. Allowing an application to pump the QUIC connection, and have the transport just deal with it without any special configuration seems attractive. In other words, if the transport is not application-limited then it can always keep the congestion window full. A scheduler can always demote such streams to behind all other streams. However, a receiver that doesn't immediately drain such streams will cause app limitation, which could affect the privacy targets. We might want to document that.
Ok that is one aspect that would benefit from clarification. I think some words on the properties that application level requested usage of reserved stream has would also be good.
NAME does the PR address your issue?
This is editorial because we're just explaining a bit more how an endpoint might use what HTTP/3 provides.
NAME Yes, this I think provides sufficient context for the padding and combined with the risks of applying it badly. So resolved.