Reviewer: Bob Halley Review result: Not Ready 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
