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

[Donald Eastlake <[e-mail]>]

Hi Lachlan,

I'm happy with all of your responses and consider my comments to have been
resolved.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]


On Thu, Mar 30, 2023 at 5:46 PM Lachlan Keller <[e-mail]>
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 <[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]
>>
>