Hi Spencer, Thanks for providing the review in a timely manner. Much appreciated.
Unless I’m mistaken, the review was not forwarded to the ALTO WG list. I’m adding the missing lists, fwiw. One quick comment on your previous comment about SETTINGS_ENABLE_PUSH, I remember the authors provided a detailed discussion of the issues your raised (see Slide 13 of https://datatracker.ietf.org/meeting/114/materials/slides-114-alto-alto-over-new-transport-01). Cheers, Med De : art <art-boun...@ietf.org> De la part de Spencer Dawkins at IETF Envoyé : vendredi 17 mars 2023 00:53 À : a...@ietf.org Objet : [art] Second early ART ART review of draft-ietf-alto-new-transport (-07) 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. <https://datatracker.ietf.org/doc/html/rfc9114#section-7.2.4.1> Defined SETTINGS Parameters<https://datatracker.ietf.org/doc/html/rfc9114#name-defined-settings-parameters> Setting identifiers that were defined in [HTTP/2<https://datatracker.ietf.org/doc/html/rfc9113>] where there is no corresponding HTTP/3 setting have also been reserved (Section 11.2.2<https://datatracker.ietf.org/doc/html/rfc9114#iana-settings>). These reserved settings MUST NOT be sent, and their receipt MUST be treated as a connection error<https://datatracker.ietf.org/doc/html/rfc9114#errors> of type H3_SETTINGS_ERROR<https://datatracker.ietf.org/doc/html/rfc9114#H3_SETTINGS_ERROR>.¶<https://datatracker.ietf.org/doc/html/rfc9114#section-7.2.4.1-5> 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. <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-3.3> Uses<https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-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. <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-4.4> Close Request<https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-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. <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-8.1> Considerations for Load Balancing<https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-considerations-for-load-bal> 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. <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-8.2> Considerations for Choosing Updates<https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-considerations-for-choosing> 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. <https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#section-8.6> Considerations for Updates to Ordinal Mode Costs<https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07#name-considerations-for-updates-t> 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! _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
