All: Happy new year. In preparation of moving alto-incr-update-sse ahead, I have performed a chair review of the work. Overall, the document is well written, mature, and considers various design tradeoffs. This is fairly mature work, and we should move it out of the WG following the resolution to the review below and an additional review by Jensen Zhang [1].
--- Begin chair review I am curious --- are there any known implementations of alto-sse? MAJOR -S10.1: This is an important discussion. However, this discussion is written primarily from a viewpoint of an ALTO client, but if I understand it correctly, it should be written from the viewpoint of an ALTO stream server since it is the stream server that is generating the event since that is the source that should be told to behave conservatively. Should this section be re-written to exhort the stream server to send out full cost maps in chunked format, where each chunk is at most 2,000 octets? That way, the clients are not overwhelmed. Thoughts? MINOR S3: It is rather unfortunate that one of the services is named “Stream Control Service” as this may be conflated by the uninitiated reader with the Stream Control Transmission Protocol (SCTP) service, a transport layer protocol. Clearly, that is not the intent here. However, I am loathe to suggest a new naming scheme this late in the document publication phase, so perhaps the best we can do now is to add a note explicitly disassociating Stream Control Service of ALTO from SCTP. Perhaps something like: s/from the update stream./from the update stream. (Note that the Stream Control Service in ALTO has no association with the similarly named Stream Control Transmission Protocol [RFC4960].)/ S4: The phrase “Using existing techniques wherever possible,” implies that you have used other, perhaps new techniques at other places. Is that the case? If so, please enumerate the new techniques; if not, perhaps reword as s/Using existing techniques wherever possible,/Using existing techniques,/ -S4.2.1: “This document adopts the JSON merge patch message format to encode incremental changes, but uses a different transport mechanism.” ==> Not sure how to interpret this. Since alto-sse uses the HTTP PATCH method to affect incremental updates, it uses the same “transport mechanism” (i.e., TLS). Perhaps you meant “..., but uses a different HTTP method, i.e., it uses POST instead of PATCH (details in Section 5).”? -S4.2.1, page 10: s/, and (3) assigns a new tag to the network map:/, (3) leaves “PID3” unmodified, and (4) assigns a new tag to the network map:/ -S6.1: Is there some magic about the numbers “1” and “2” assigned to substream IDs? In other words, must substream IDs begin with 1 and monotonically increase? If so, state that. If not, then state that substream IDs must begin with a random number between [1, 10] and monotonically increase from there on for each new substream. That is, if the first substream ID is 6, then subsequent substream IDs from the client should monotonically increase from this starting value. (I will let the protocol designers come up with the exact text to impart this.) NITS -S5, page 16: s/this design allows/this document allows/ (Overworked use of “design”: “...flexible protocol design, this design…”). -S10.1: s/single character array./character array./ -S10.1: s/client computer/client/ --- End of chair review Additionally, the work has also been reviewed by Jensen [1]. Authors, please attend to the comments indicated in this review and Jensen's review and release a new version in order to move the work forward.. [1] https://mailarchive.ietf.org/arch/msg/alto/C9_tS44bz7kq84Z3cpZZkMeUDFc Thank you. - vijay
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
