[alto] Éric Vyncke's Abstain on draft-ietf-alto-new-transport-17: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-alto-new-transport-17: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-alto-new-transport-17

Thank you for the work put into this document even if I am not too satisfied by
the whole document, hence my ABSTAIN position per "I cannot support sending
this document forward." (see
https://www.ietf.org/standards/process/iesg-ballots/) FYI, I stopped reviewing
it after section 2 as my ballot position was already forged.

Please find below one blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.

Special thanks to Mohamed Boucadair for the shepherd's detailed write-up
including the WG consensus and the justification of the intended status.

Other thanks to Bob Halley, the Internet directorate reviewer (at my request),
please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-alto-new-transport-16-intdir-telechat-halley-2023-10-19/
(review dated 19th of October and I have yet to read a reaction from the
authors, comforting my ABSTAIN as I share Bob's concerns)

Other thanks to Wesley Eddy, the IoT directorate reviewer (at my request),
please consider this iot-dir review:
https://datatracker.ietf.org/doc/review-ietf-alto-new-transport-17-iotdir-telechat-eddy-2023-10-23/
(and I have read Kai's reply)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## Abstract

The use of HTTP/1.1, HTTP/1.x, HTTP/2, HTTP/3 in the same paragraph is *really*
confusing. Consider aligning the version to be consistent.

## Section 1

Like already written by other ballots, let's simply s/two transport
protocols/two protocols/

In `and the server sends the complete content of the requested information (if
any) resource to the client`, is it about an ALTO client or an application
client ?

## Section 2.1

`Incremental updates can reduce both the data storage on an ALTO server`
hummm... in order to send increments, the server must keep all those increments
for all its clients. I.e., increasing the data storage. Please either correct
me (I would be happy) or the text.

Is 'prefetching' the right term ? It relates to client-initiated fetch rather
than server-initiated push.

I strongly object (but not a block DISCUSS level) to `as many development tools
and current ALTO implementations are based on HTTP/1.1.`. An IETF protocol
design cannot be bound by 2023 implementations, e.g., else IPv6 would have
never been standardized.

Where is the data model defined in `The key idea is to introduce a unified data
model to describe the changes ` ?

# NITS

## Abstract

Should s/defines/define/ in `ALTO incremental updates using Server-Sent Events
(SSE) (RFC 8895) defines a multiplexing protocol on top of HTTP/1.x`

## TIPS

I am not a native English speaker, and it is probably too late, but s/Transport
Information Publication Service/Information Transport Publication Service/
sounds better to my French-speaking ears.