Telechat Review of draft-ietf-alto-new-transport-16
review-ietf-alto-new-transport-16-intdir-telechat-halley-2023-10-19-00

I am an assigned INT directorate reviewer for draft-ietf-alto-new-transport.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, if I was on the IESG I would ballot this document as
DISCUSS.

While I don't know much about ALTO, I have worked extensively with
sequence-number-based versioning systems with both snapshots and incremental
updates.

I have the following DISCUSS/ABSTAIN level issues:

I think the basic design is sound; my problem is really with the way the
document is written.  Some sections are repetitive, some are well-specified,
and others seem to be examples with explanatory (but also normative) text.  The
example-type sections felt fuzzy and underspecified.  For example, if I do

  GET /tips/2718281828459/ug/102/105

in a case where there is no "optional" incremental update edge from 102 to 105,
i.e. I have to get 102->103, 103->104, and 104->105 individually, then it is
not clear to me what happens.  Do I get 404?  I think this document would be
very frustrating for prospective implementers.

An architectural worry is that I didn't see any notion of a "generation id" or
"database id" or other unique name for the whole version history.  Generally
speaking there is always a possibility of the replacement/regeneration of the
entire database due to a catastrophic server failure or operator error.  As
part of the recovery, new content is loaded and the prior version history is
invalidated.  Ideally a client connecting would realize this and start from 0
again, as opposed to asking from incremental changes from a history that
doesn't exist any more.  The issue is that the sequence number spaces of the
two histories might overlap, and thus the client might be given a nonsensical
diff that would not apply instead of learning it needs to resync from scratch. 
In some cases, this can lead to subtle and hard-to-detect content divergence.

Dependencies between different versioned objects, as discussed in 8.3, is
understandable but also seems to undercut simple long pulling of individual
URIs.  I'm not objecting to the dependencies themselves, as this is
unavoidable.  I wonder if this might have been addressed in some other way that
was less burdensome to clients, e.g. some sort of "versioned set of versions",
though I grant this is not an easy problem.  It just felt late to hear about it
in section 8.3 when the rest of the text seems to be encouraging me to long
pull without other concerns.

On the nit level, I found the use of "prefetch" as a synonym for "long pull"
confusing, as for me "prefetching" is a speculative caching term.  There is no
speculation or caching going on here, we're just trying to do a "push" style of
pubsub via "long polling" instead of repetitive polling or another form of push
notification.