Skip to main content

Last Call Review of draft-ietf-alto-new-transport-14
review-ietf-alto-new-transport-14-httpdir-lc-thomson-2023-09-26-00

Request Review of draft-ietf-alto-new-transport
Requested revision No specific revision (document currently at 22)
Type Last Call Review
Team HTTP Directorate (httpdir)
Deadline 2023-10-06
Requested 2023-09-22
Authors Kai Gao , Roland Schott , Y. Richard Yang , Lauren Delwiche , Lachlan Keller
I-D last updated 2023-09-26
Completed reviews Httpdir Last Call review of -14 by Martin Thomson (diff)
Secdir Last Call review of -15 by Donald E. Eastlake 3rd (diff)
Genart Last Call review of -15 by Linda Dunbar (diff)
Iotdir Telechat review of -17 by Wesley Eddy (diff)
Intdir Telechat review of -16 by Bob Halley (diff)
Artart Early review of -01 by Spencer Dawkins (diff)
Secdir Early review of -07 by Donald E. Eastlake 3rd (diff)
Opsdir Early review of -07 by Sheng Jiang (diff)
Rtgdir Early review of -07 by Russ White (diff)
Tsvart Early review of -07 by Dr. Bernard D. Aboba (diff)
Artart Early review of -07 by Spencer Dawkins (diff)
Httpdir Early review of -07 by Martin Thomson (diff)
Assignment Reviewer Martin Thomson
State Completed
Request Last Call review on draft-ietf-alto-new-transport by HTTP Directorate Assigned
Reviewed revision 14 (document currently at 22)
Result Not ready
Completed 2023-09-26
review-ietf-alto-new-transport-14-httpdir-lc-thomson-2023-09-26-00
I reviewed the document previously, so this is an incremental review.

Two major issues remain in the document.  I don't believe that it would be
responsible to publish this document without correcting these issues.

1. The first relates to assumptions of connection-bound state and a fix would
require some small, but fundamental, changes to the protocol.

2. The second relates to the appendix on use of HTTP server push and might be
fixed either by dropping the capability along with some minor editorial
changes, or by reworking the design of the appendix.

A lot of the explanation of the data model and the expected interaction models
are clearer in this version.  The polling design seems reasonable, modulo the
first issue I note below.  That said, I am not expert enough in this area to
say whether there is a need to create per-client state on servers to support
this interaction mode.

Issue 1: Connection affinity

Section 4.2 of the document is a defense of the decision in the protocol that
binds state to a connection.  HTTP does not recognize connections as having any
state.  The last paragraph of Section 4.11 of RFC 9205 explains this very
clearly:

> Applications MUST NOT make assumptions about the relationship between
separate requests on a single transport connection; doing so breaks many of the
assumptions of HTTP as a stateless protocol and will cause problems in
interoperability, security, operability, and evolution.

There are several recognized ways of working around the sorts of issues that
this document is trying to deal with.  One might be to build a stateful
protocol that is not HTTP (as in Section 2.1 of RFC 9205).

If the goal is to use HTTP, then you might be able to provide clients with URLs
that only reference the server instances that they are currently interacting
with.  For instance, when the client opens a new TIPS view, the server could
provide an absolute URL to a resource that is hosted exclusively on that
instance (for instance, instance12345.alto.example as opposed to alto.example).
 Clients would still be able to use the URL template style of queries relative
to that view, but the state would not be assumed to exist across the entire
service.

This approach has some drawbacks, in that it can expose instances to more
powerful denial of service attacks, but it might provide the sort of properties
that Section 4.2 claims to be seeking.

Issue 2: Server push design

The use of HTTP server push described in Appendix C is not consistent with
HTTP/2 or HTTP/3 and will not work.

I've attempted to explain several times why this design is unworkable.  I won't
try again here.

Cheers,
Martin