This is my second early review of this document - the first was a review of -01. 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 0x02 SETTINGS_ENABLE_PUSH (a BCP14 “MUST”) has been addressed. As I pointed out in my previous review RFC 9114 reserves this value in the parallel HTTP/3 registry ( https://www.rfc-editor.org/rfc/rfc9114.html#iana-setting-table), and says this about these reserved values in https://www.rfc-editor.org/rfc/rfc9114.html#section-7.2.4.1: 7.2.4.1. 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 H3_SETTINGS_ERROR .¶ 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 3.3. Uses 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 paragraph? In 4.4. Close Request 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, 8.1. Considerations 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 8.2. Considerations 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). and 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 8.6. Considerations 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!