[alto] Protocol Action: 'The ALTO Transport Information Publication Service' to Proposed Standard (draft-ietf-alto-new-transport-22.txt)

[The IESG <[e-mail]>]

The IESG has approved the following document:
- 'The ALTO Transport Information Publication Service'
  (draft-ietf-alto-new-transport-22.txt) as Proposed Standard

This document is the product of the Application-Layer Traffic Optimization
Working Group.

The IESG contact persons are Zaheduzzaman Sarker and Martin Duke.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/




Technical Summary

   The ALTO Protocol (RFC 7285) leverages HTTP/1.1 and is designed for
   the simple, sequential request-reply use case, in which an ALTO
   client requests a sequence of information resources, and the server
   responds with the complete content of each resource one at a time.

   ALTO incremental updates using Server-Sent Events (SSE) (RFC 8895)
   defines a multiplexing protocol on top of HTTP/1.x, so that an ALTO
   server can incrementally push resource updates to clients whenever
   monitored network information resources change, allowing the clients
   to monitor multiple resources at the same time.  However, HTTP/2 and
   later versions already support concurrent, non-blocking transport of
   multiple streams in the same HTTP connection.

   To take advantage of newer HTTP features, this document introduces
   the ALTO Transport Information Publication Service (TIPS).  TIPS uses
   an incremental RESTful design to give an ALTO client the new
   capability to explicitly, concurrently (non-blocking) request (pull)
   specific incremental updates using native HTTP/2 or HTTP/3, while
   still functioning for HTTP/1.1.

Working Group Summary

No controversy was raised during the development of this specification from the
WG participants. There were some discussions about various design options to
meet the new transport requirements, naturally. These options were presented
and discussed in many WG meetings. No objections from the WG were raised
against the actual design (especially during the two WGLCs organized for this
document).

Some concerns were raised by some directorate reviewers, e.g., server Push
usage, 1:1 relationship between clients and connections, etc. The document
includes NEW text to motivate these design choices when appropriate. The
specification was also updated to reflect the comments from the reviewers
(e.g., ordering requirement, explicit the transport requirements, avoid the
impression of design-by-example by indicating the expected behavior (e.g.,
increment by 1), etc.

The author also included a new section to describe to what extent this work
adheres to "Building Protocols with HTTP" BCP. The authors also updated the
language to align with the recommendation in RFC9205#Section 3.1.

During the IETF LC, the server Push usage and 1:1 relationship between clients
and connections were re-challenged, especially given the considerations in the
last paragraph of Section 4.11 of RFC 9205. As an outcome, the design was
updated by removing the 1:1 connection affinity and the appendix related to
Server Push. The text was also updated to highlight the URLs that point to
specific server instances.

Document Quality

There is one known implementation.

Personnel

   The Document Shepherd for this document is Mohamed Boucadair. The
   Responsible Area Director is Martin Duke.