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

Document: draft-ietf-httpbis-incremental
Title: Incremental Forwarding of HTTP Messages
Reviewer: Tina Tsou
Review result: Has Issues

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

Reviewer: Tina Tsou
Review result: Has Issues
Review type: OPS-DIR Last Call Review
Document: draft-ietf-httpbis-incremental-03
Intended Status: [Standards Track/Informational/BCP]
Review Date: 2025-12-25

## Summary

The draft specifies an “incremental” mechanism for HTTP that enables a sender
to deliver response content in smaller units so a client can make earlier
progress while the transfer continues. From an operations perspective, the
document is broadly readable and motivated, but several behaviors that
materially affect intermediaries, caching, error handling, and observability
need clearer specification. I believe these issues are addressable with focused
edits.

## Major Issues

1) Intermediary behavior not fully specified
   - The draft should normatively state what HTTP proxies, gateways, and CDNs
   are permitted or required to do when forwarding incremental responses. In
   particular:
     • Whether incremental framing/chunks may be coalesced or buffered by
     intermediaries. • How an intermediary signals to downstream clients that
     the response is no longer incremental if it buffers. • Requirements for
     hop-by-hop vs end-to-end headers related to incremental delivery.

2) Cache interaction and revalidation
   - Clarify whether an incremental response is cacheable while still in
   progress and which validators apply to partially received representations. -
   Define expected behavior for conditional requests when only a prefix of the
   representation was cached. - State whether Range requests can be combined
   with incremental delivery and how that affects caching semantics.

3) Error handling and partial integrity
   - Specify client-observable signals when the transfer fails mid-stream after
   some increments were processed. - If integrity mechanisms (e.g., per-chunk
   digests or a manifest) are in scope, they should be referenced normatively;
   if not, the draft should explicitly state integrity is out of scope and
   advise deployments accordingly.

4) Negotiation and fallback
   - Describe capability discovery and downgrade behavior: how a server decides
   to send incremental vs non-incremental, and what a client must do if it does
   not support incremental delivery. - Make sure the ABNF and precedence rules
   are explicit if new headers or parameters are introduced.

## 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.

- 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.

- 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.

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

## Nits and Editorial

- Define “increment,” “unit,” or “chunk” once and use consistently.
- Provide a minimal end-to-end example exchange, including request, response
headers, a few increments, and completion. - Expand acronyms on first use and
add a short terminology section. - Run the document through idnits and fix any
boilerplate or reference warnings.

## 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. - Backward-compatibility statement indicating
safe deployment alongside legacy clients and intermediaries.

## Security Considerations (ops-relevant)

- Note potential amplification if many small increments are used and recommend
rate limiting. - Discuss risks of content confusion if intermediaries splice or
coalesce increments; reinforce end-to-end integrity guidance where applicable.
- Call out logging privacy considerations when exposing per-increment metadata.

## Implementation Status (optional but helpful)

- If any known client/server prototypes exist, add a brief note or remove the
section if none are known.

Conclusion: With clarifications to intermediary behavior, caching, error
handling, and negotiation, the draft will be operationally clearer and safer to
deploy.

Received on Thursday, 25 December 2025 08:08:12 UTC