Hi Donald, Thank you so much for your review and comments. Please see the responses inline.
Best, Lachlan On Tue, Mar 28, 2023 at 11:10 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 comments. > > The summary of the review is Ready with Nits. > > *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. There are a few additional > security considerations which seem to be well covered by the Security > Considerations section of this draft. > > *Nits:* > > Section 1.0, Page 4: > OLD > functioning for HTTP/1.x. TIPS also provides an ALTO server to > NEW > functioning for HTTP/1.x. TIPS also provides for an ALTO server to > LACHLAN: fixed > > Section 2.1.1, Page 8: Seems too vague. A sentence about tips-view-uri > wouldn't hurt. At the bottom it says "Use the URI as above". Which URI > above? What exactly does "use" mean? > LACHLAN: Thanks for this comment - propose changing "Use the URI as above" to "Construct same URIs as with client pull for push promise URIs." As for the tips-view-uri clarification, propose adding "<tips-view-uri> // relative URI to TIPS view (see Section 4.2)" > > Section 2.2, Page 9, Figure 3: Figure looks kind of incomplete. Shouldn't > there be arrows from R1 to R2/R3? > LACHLAN: You are right that figure 3 is technically incomplete. We will move it to the appendix as it was supposed to just show the thought process of part of the design decisions we made. > > Section 2.3, Page 10: In the text on "Information Resource Directory" the > first sentence is confusing. What is the thing that is requested to > discover? Maybe you should replace "Requested" at the start of the sentence > with "Produced when a server is requested"... > LACHLAN: Propose changing text to "Contains a list of available information resources provided by an ALTO server that can be requested by ALTO clients" to clarify the section. > > Section 2.3, Page 11 at top: That's Figure 4, not 1. > LACHLAN: good catch > > Section 2.4, Page 12, 1st paragraph: I think a service runs "over" a > connection, not "inside" a connection. > LACHLAN: fixed > > Section 4.4, Page 23: Seems kind of feeble. How about, given that a > disconnect is treated as a DELETE, something like the following, which > probably implies that the server maintains a use count. (This document need > not mention such a count.) > OLD > set associated with the TIPS view. A server will not want to delete > NEW > set associated with the TIPS view. A server MUST NOT delete > > LACHLAN: Great point. Because there are actually multiple options with how to treat the DELETE, we’ve now added a new considerations section that discusses management of shared TIPS views for clarity. See Kai’s response to the ART ART review for more details, where this was pointed out as well. > > 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
