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.