Hi Roman, Thanks for the update. We adopt the nits and propose the following text in Sec 9:
Additionally, operators of the ALTO servers MUST follow the guidelines in [RFC9325] to avoid new TLS vulnerabilities discovered after [RFC7285] was published. Please let us know if that makes sense. Thanks! Best, Kai > -----Original Messages----- > From: "Roman Danyliw via Datatracker" <[email protected]> > Send time:Wednesday, 01/03/2024 04:49:26 > To: "The IESG" <[email protected]> > Cc: [email protected], [email protected], > [email protected], [email protected], [email protected] > Subject: Roman Danyliw's No Objection on draft-ietf-alto-new-transport-21: > (with COMMENT) > > Roman Danyliw has entered the following ballot position for > draft-ietf-alto-new-transport-21: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to Donald Eastlake for the SECDIR review. > > Thanks for addressing my DISCUSS feedback. > > ** Section 6.2. Editorial. New text was added clarifying text to prescribe > that TIPS view URI must not be reused. I would recommend being a clearer on > this language. > > OLD > A server MUST NOT use a URI for different TIPS views, either for > different resources or different request bodies to the same > resource. > NEW > A server MUST NOT use the same URI for different TIPS views, either for > different resources or different request bodies to the same resource. > > ** Section 9. > The security considerations (Section 15 of [RFC7285]) of the base > protocol fully apply to this extension. For example, the same > authenticity and integrity considerations (Section 15.1 of [RFC7285]) > still fully apply; > > Since ALTO TIPS is a new protocol mechanism is it possible to improve on the > TLS guidance in Section 8.3.5 of RFC7295 (from circa 2014)? Specifically, can > RFC9325 be mandated? > > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
