Re: draft-ietf-httpbis-incremental-03 ietf last call Opsdir review

Hi Tina,

I think that Mark's response covers your major point effectively.  I'll respond inline to your other points.

I don't know if this review was prepared by an LLM -- and I apologize if I'm reading too much into this; I find that they can be helpful -- but there are a few points where it looks like review instructions were copied directly into your review.  I've skipped those points.

On Thu, Dec 25, 2025, at 19:08, Tina Tsou via Datatracker wrote:
> ## Minor Issues
>
> - Server push and HTTP/2/HTTP/3 mapping
>   Provide a short subsection on how incremental delivery maps across HTTP/1.1,
>   HTTP/2, and HTTP/3, including any transport-level interactions (flow control,
>   HEADERS/DATA framing, QUIC stream limits). If any version is out of scope,
>   say so.

This probably falls under the same rubric as Mark's points, but just to cover the high points, this is an HTTP feature that is version-agnostic. It isn't necessary to specify where we aren't touching the protocol.  The opposite even: enumerating how a feature works for each version is more distracting to a reader than helpful.  That is, people might read text on the subject and infer that special per-version handling is necessary where it is not. The same applies to server push.

> - Observability and logging
>   Recommend at least one metric (e.g., number of increments, average increment
>   size, time-to-first-increment) and clarify that status code remains stable
>   across increments.

Logging requirements for a protocol like HTTP are not generally specified in that way.  If this were a product specification, maybe.  But we are defining an interoperability standard, so these are not appropriate.  That's not to say that there would be no value in follow-up work on what might be implemented to make it easier to operate intermediaries that comply with this spec.  However, that's not a common practice with this protocol, even if some progress has been made (see qlog, though that's at a different layer).

As this relates to message bodies or content, restating that a status code applies to the entire message is not necessary for the same reasons as for the last point.

> - Content codings and trailers
>   Clarify ordering when content codings (e.g., gzip) and trailers are used with
>   incremental delivery. State if trailers can carry final integrity or size
>   information.

Again, this is limited to the delivery of content.  There are interactions with codings, but those considerations generally apply to codings, which might have constraints on what can be processed incrementally.

> - IANA considerations
>   If new headers or parameters are defined, ensure each has a precise IANA
>   registry action with references and examples.

I'm going to chalk this up as an item from the checklist.

> ## Nits and Editorial
>
> - Define “increment,” “unit,” or “chunk” once and use consistently.

As far as I can see none of these terms appear in the document.

> - Provide a minimal end-to-end example exchange, including request, response
> headers, a few increments, and completion. 

In this case, I'm going to decline.  The important aspect (delivery of content bytes) cannot be illustrated easily.  There are examples of the header field, which I consider sufficient.

> - Expand acronyms on first use and
> add a short terminology section.

The only acronyms we use are "HTTP" and "API".  These are in the abbreviation list: https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list

> - Run the document through idnits and fix any
> boilerplate or reference warnings.

More checklist boilerplate?  (FWIW, idnits seems fine, aside from some warnings about non-ASCII text, which we absolutely need.)

> ## Operational Considerations
>
> - Guidance for default server limits to avoid resource exhaustion (e.g.,
> maximum number of concurrent incremental responses, minimum increment size). 
> - Advice for CDNs/load balancers about buffering thresholds and when to preserve
> or disable incremental behavior.

Guidance is provided, though no concrete values are included, because that would be inappropriate.  Those values have performance, security,and operational implications.  Deployments need to be able to choose values that suit their needs.

> - Backward-compatibility statement indicating
> safe deployment alongside legacy clients and intermediaries.

This is a good point.  It came up in another review, so we've already added a note (and tweaked some of the language); see https://httpwg.org/http-extensions/draft-ietf-httpbis-incremental.html#section-1-10

> ## Security Considerations (ops-relevant)
>
> - Note potential amplification if many small increments are used and recommend
> rate limiting.

Amplification isn't really possible here, though we do have a section on small packets and their inefficiency.  (Note that this is only something that the intermediary can improve, not eliminate, with buffering.  And there is no way that an intermediary can be used as an amplifier with HTTP, with or without this extension, unless it chooses that behavior.)

> - Discuss risks of content confusion if intermediaries splice or
> coalesce increments; reinforce end-to-end integrity guidance where applicable.

I think this falls under the same point as the first: this consideration is not changed by the feature, so adding text would be misleading.

> - Call out logging privacy considerations when exposing per-increment metadata.

Is this specifically about logging?  Because we already address the privacy implications that come from incremental forwarding.  (To be clear, those are not unique to this extension, but we consider it worth highlighting because intermediaries might change their behavior due to this extension in ways that could have privacy consequences.)

> ## Implementation Status (optional but helpful)
>
> - If any known client/server prototypes exist, add a brief note or remove the
> section if none are known.

There are a few implementations in deployment, but it is not common practice in this community to memorialize the current state of implementations.

Received on Monday, 5 January 2026 04:28:19 UTC