Last Call Review of draft-ietf-alto-new-transport-14
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