Skip to main content

Early Review of draft-ietf-alto-new-transport-07

Request Review of draft-ietf-alto-new-transport
Requested revision No specific revision (document currently at 19)
Type Early Review
Team ART Area Review Team (artart)
Deadline 2023-03-28
Requested 2023-03-13
Requested by Mohamed Boucadair
Authors Kai Gao , Roland Schott , Y. Richard Yang , Lauren Delwiche , Lachlan Keller
I-D last updated 2023-03-16
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)
The document is currently in the WGLC. Directorate review comments will be addressed as part of the WGLC. 

Thank you.
Assignment Reviewer Spencer Dawkins
State Completed
Request Early review on draft-ietf-alto-new-transport by ART Area Review Team Assigned
Posted at
Reviewed revision 07 (document currently at 19)
Result Ready w/issues
Completed 2023-03-16
This is my second early review of this document - the first was a review of

My "Ready with Issues" is based solely on the number of references to
HTTP/3 server PUSH usage, which was tagged in my earlier review.

Beyond that, and the following nits, the document was easy and pleasant for
me to follow.

Best wishes to the working group!

I know a lot of things changed in this draft since I early-reviewed -01 -
I'm now early-reviewing -07 - but I'm not sure that my previous observation
about this HTTP setting


has been addressed.

As I pointed out in my previous review RFC 9114 reserves this value in the
parallel HTTP/3 registry (, and says
this about these reserved values in <>Defined
SETTINGS Parameters

Setting identifiers that were defined in [HTTP/2
<>] where there is no
corresponding HTTP/3 setting have also been reserved (Section 11.2.2
<>). These
reserved settings MUST NOT be sent, and their receipt MUST be treated
as a connection
error <> of type

I don't know what needs to be changed in this specification to reflect
this, but even the abstract and the last paragraph of the Introduction
refer to "native HTTP/2 or HTTP/3 server push".

Section 2.4 and 2.5 address the use of TIPS inside an HTTP/1.x connection,
which doesn't support server push, so I know you folks have thought about
how that works.Do you need to address this for HTTP/3 as well?

More strategically, should you be encouraging clients to add support for
server PUSH in a new application protocol, if it's already been removed
from HTTP/3? But I see this document is in WGLC now, so you can think about
that and Do The Right Thing.

I have some BCP 14 questions about this text in


This set may be any subset of the ALTO server's network information
resources and may include resources defined in linked IRDs. However, it is
RECOMMENDED that the ALTO server selects a set that is closed under the
resource dependency relationship. That is, if a TIPS' "uses" set includes
resource R1 and resource R1 depends on ("uses") resource R0, then the TIPS'
"uses" set SHOULD include R0 as well as R1. For example, a TIPS for a cost
map SHOULD also provide a TIPS view for the network map upon which that
cost map depends.

I have the same question about R1 and R0, but let's start with a specific
case. If a TIPS for a cost map does not also provide a TIPS view for the
underlying network map, what happens next?

(Nit) is there a missing term after TIPS in "a TIPS for a cost map" in this

In 4.4.

An ALTO client can indicate it no longer desires to pull/receive updates
for a specific network resource by "deleting" the TIPS view using the
returned tips-view-uri and the HTTP DELETE method. Whether or not the
server actually deletes the TIPS view is implementation dependent. Likely,
a server will remove the client from a dependency set associated with the
TIPS view. A server will not want to delete a TIPS view if another client
is using it.

I'm guessing here, but this looks like it's conflating client usage with
server storage management. If client A says "delete the TIPS view", and no
other client is using it, that view is deleted, but if another client is
using it, and the view is not deleted, what happens next? I could imagine
that a server might delete the underlying TIPS view when all clients who
were using it have deleted it. Does server behavior in this case need to be
implementation dependent?

In this text,
for Load Balancing

TIPS allow clients to make concurrent pulls of the incremental updates
potentianlly through different HTTP connections. As a consequence, it
introduces additional complexties when the ALTO server is being load
balanced -- a feature widely used to build scalable and fault-tolerant web
services. For example, a request may be incorrectly processed if
   the backend servers are stateful, i.e., the TIPS view is created and
   stored only on a single server;
   the ALTO server is using layer-4 load balancing, i.e., the requests are
   distributed based on the TCP 5-tuple.

are these conditions ANDed, or ORed? Is either condition sufficient to
cause a problem, or are both required?

Also, in the last paragraph of this section,


   For example, the ALTO server may configure layer-7 load balancers that
   distribute requests based on URL or cookies.

Isn't this talking something that an operator or provider of the ALTO
server would do, rather than the ALTO server itself?

I have a similar question about
for Choosing Updates

TIPS should be cognizant of the effects of its update schedule, which
includes both the choice of timing (i.e., when/what to trigger an update on
the updates graph) and the choice of message format (i.e., given an update,
send a full replacement or an incremental change).


Therefore, each TIPS may decide on its own whether to use JSON merge patch
or JSON patch according to the changes in network maps.

is TIPS thinking, or is that up to a human?

And in
for Updates to Ordinal Mode Costs

While this document allows TIPS to offer incremental updates for ordinal
mode cost maps, TIPS implementors should be aware that incremental updates
for ordinal costs are more complicated than for numerical costs, and ALTO
clients should be aware that small changes may result in large updates.

I'm guessing that ALTO clients aren't aware.

I'm not sure I've caught all of these occurrences, but perhaps the GenArt
reviewer will notice others, if they are present!