Hi Kai! The proposed text works for me. Thank you. I appreciate you also merging the clarifying editorial text.
Roman > -----Original Message----- > From: iesg <[email protected]> On Behalf Of [email protected] > Sent: Wednesday, January 3, 2024 7:07 AM > To: Roman Danyliw <[email protected]> > Cc: The IESG <[email protected]>; [email protected]; alto- > [email protected]; [email protected]; [email protected] > Subject: Re: Roman Danyliw's No Objection on draft-ietf-alto-new-transport- > 21: (with COMMENT) > > Warning: External Sender - do not click links or open attachments unless you > recognize the sender and know the content is safe. > > > 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-posi > > tions/ 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
