Gorry Fairhurst has entered the following ballot position for draft-ietf-regext-epp-quic-10: Discuss
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-regext-epp-quic/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Please find below a blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the point below, which I expect will be very easy to resolve: ## The current text says: "Operators are encouraged to provision network paths with appropriate MTU sizes to avoid packet fragmentation for EPP message delivery." - I don't really understand what this is asking for and what is needed, please clarify. - When I started reading I assumed this was the standard QUIC datagram size (as in section 14), but maybe this means to say more, or I was just thrown by the term "MTU" here? - And please explain what is the fragmentation described here? ## Please consider and respond to Zahed's review comment: RFC 9000 defines max_ideal_timeout ( https://datatracker.ietf.org/doc/html/rfc9000#idle-timeout ), section 3 of this draft does not relate to usage of that max_ideal_timeout but states -"the server MAY end the QUIC connection immediately". How is it supposed to work with the max_ideal_timeout if that is negotiated at the connection setup? ## Section 4 says - A server SHOULD limit a client to a maximum number of QUIC streams per QUIC connection based on server capabilities and operational load. How do you do that via RFC9000? Or is this something new? If you are using RFC9000, then add a reference to the concurrency control described in RFC9000. or explain how your intent to enforce the SHOULD. ## Section 10.6 says - EoQ servers MUST utilize the QUIC Retry Packet mechanism described in Section 8.1.2 of [RFC9000]. As RFC9000 does not apply MUST to use QUIC Retry Packets for address validation, what is the justification for the MUST here? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for submitting this document, I have the following (non-blocking) comments: ## I couldn't really understand why this RFC is specifying transport over QUIC, but expect there was some specific need. I think that ought to be clearer. ## The security properties of QUIC do differ to those of TLS/TCP, in as much as QUIC us an encrypted transport - see 21.1 in the security considerations of RFC9000. # Please address the issues raised by Zahed as a part of his TSVART review: ## Even though section 3 explains it the correct way, in section 6, it says - The EoQ Connection Start Packet is written by the client after creating a QUIC stream to signal to the server to create the QUIC stream. This is inaccurate when client-initiated bi-directional streams are used. The server does not create streams; it just uses the streams created by the client. The snipped emphasizes that "signal to the server to create stream " that needs to be fixed. If there are no specific explanations, then it would suggest to rewrite the sentence to -- The EoQ Connection Start Packet is sent by the client after creating a QUIC connection to signal to the server, on the client-initiated stream, respond with EPP<greeting>. # Nits - - Section 7 : the references to RFC9000 are out of order in the description of "Stateful Nature". RFC 9000 section 2 is about streams and section 5 is about connections. Best wishes, Gorry _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
