Re: [alto] SECDIR review of draft-ietf-alto-new-transport-07

[Lachlan Keller <[e-mail]>]

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 <[e-mail]> 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   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [e-mail]
>