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

Hi Tina,

Thanks for the review. I'll let the authors respond to individual points, but I notice that many of your comments are about specifying the interactions between different HTTP features and incremental. 

In general, HTTP features are defined to be self-describing and backwards-compatible; a new extension like incremental shouldn't change (for example) caching semantics, because it's not reasonable to expect all participants in an exchange to be aware of them. 

So, this specification doesn't change (for example) how hop-by-hop headers work, or how caches work, or how digests work, or how partial content request work -- these features are effectively isolated. Also, if a client doesn't support incremental, this specification (like any HTTP extension) can't place new requirements upon it, so it isn't required to do anything.

Cheers,



> On 25 Dec 2025, at 7:08 pm, Tina Tsou via Datatracker <noreply@ietf.org> wrote:
> 
> 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.
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Thursday, 25 December 2025 21:17:09 UTC