Hi Lachlan, I'm happy with all of your responses and consider my comments to have been resolved.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] On Thu, Mar 30, 2023 at 5:46 PM Lachlan Keller <[email protected]> wrote: > 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
