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@gmail.com