Re: [alto] Roman Danyliw's No Objection on draft-ietf-alto-new-transport-21: (with COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Kai!

The proposed text works for me.  Thank you.  I appreciate you also merging the clarifying editorial text.

Roman

> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of [e-mail]
> Sent: Wednesday, January 3, 2024 7:07 AM
> To: Roman Danyliw <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; alto-
> [e-mail]; [e-mail]; [e-mail]
> 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" <[e-mail]> Send
> > time:Wednesday, 01/03/2024 04:49:26
> > To: "The IESG" <[e-mail]>
> > Cc: [e-mail], [e-mail],
> > [e-mail], [e-mail],
> > [e-mail]
> > 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?
> >
> >