HI Kai, Thanks for your response which sounds good. I'll consider my issues resolved.
Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] On Wed, Nov 1, 2023 at 9:54 AM Kai GAO <[email protected]> wrote: > > Hi Donald, > > Sorry for the late reply as the mail is not properly forwarded to my > primary email. Please see our responses inline and feel free to let us know > if there are further comments. > > Best, > Kai > > On Thu, Oct 12, 2023 at 10:38 AM Donald Eastlake <[email protected]> wrote: > >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. Document editors and WG chairs should treat these comments just >> like any other last call comments. Sorry this review is a bit late. >> >> The summary of this review is Ready with Issues. >> >> (I did an early review of the -07 version of this draft at which time >> I found only nits all of which were fixed.) >> >> *Security* >> >> While I'm not all that into ALTO, it seems to me that this draft is all >> about messages and message exchanges between ALTO entities where the >> security (authentication, encryption, ...) has been specified in previous >> standards track documents such as RFC 7285; however, in Section 9.3, >> it says the spoofed URIs can be avoided by "encrypting the requests" >> where I think it should say "authenticating" the requests. There are a >> few additional security considerations which seem to be covered by the >> Security Considerations section of this draft. >> > > [KAI] You are right. In the meantime, after discussing with the AD and the > HTTPDIR reviewer, we eventually dropped the design of explicitly deleting a > TIPS view. So, it seems that spoofed URI is no longer a concern. > > >> >> *Other possible issues* >> >> - In the update from -14 to -15, huge numbers of all caps RFC 2119 key >> words have been lowercased. In many instances, this does not look >> right to me. (There are many other cases but one example is that in >> Section 8.4, all words in all upper case were lowercased.) >> >> > [KAI] We went over the keywords and hopefully they are in the right case > now. Some of the operational consideration sections are repetitive to > sections in RFC 8895 and are removed in -17, including Sec 8.4 in -15. > > >> - Although there is correct text elsewhere, the last paragraph of >> Section 6.4, page 24, seems to say you delete a TIPS view if >> heartbeats time out on one connection for that view. But shouldn't it >> be all connections going away as there might be multiple? >> >> > [KAI] Yes indeed. However, the heartbeat mechanism is no longer needed as > the server now has full control of TIPS views' lifecycles. But similarly, > the server is > > >> - I am a bit surprised there is nothing about jittering the heartbeat >> messages to be sure they can't get synchronized between muldtiple >> clients. Something like the time between them should be varied by an >> amount randomly selected in the range +0% to -40%. >> >> > [KAI] Previously the idea was to use multiple heartbeat messages to detect > the liveness of clients. Even for 2 messages, the variation is 100%, which > should be good enough. Of course, as we no longer have the heartbeat > mechanism now, this probably will not be an issue anymore. > > >> - Section 2.1, Page 6: I think there is something not quite right with >> the sentence "Prefetching updates can reduce the time to send the >> request, making it possible to achieve sub-RTT transmission of ALTO >> incremental updates." It seems muddled. Transmission speed / >> transmission time isn't affected by prefetching although, of course, >> the time to satisfy a request can be vastly reduced. Maybe >> "Prefetching updates can reduce the time to satisfy a request, makit >> it possible to achieve rapid, sub-RTT ALTO incremental updates." >> >> > [KAI] Thanks for the proposal. Will use the suggested text. > > >> >> *Nits* >> >> - Section 3.1, page 10, "(tag" -> "(a tag" >> > > [KAI] Nice catch. Updated as suggested. > > >> >> - Section 6.2, page 22, "time unit is second" -> "time unit is a second" >> > > [KAI] The sentence is no longer there as heartbeat is removed in the new > version. > > >> >> Hope these comments are helpful. >> >> Thanks, >> Donald >> =============================== >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 2386 Panoramic Circle, Apopka, FL 32703 USA >> [email protected] >> >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto >> >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
