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. *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.) - 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? - 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%. - 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." *Nits* - Section 3.1, page 10, "(tag" -> "(a tag" - Section 6.2, page 22, "time unit is second" -> "time unit is a second" Hope these comments are helpful. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@xxxxxxxxx -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
