Hi, Thank you for the review and below are responses to your feedback prefixed with "JG-".
-- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/15/26, 7:09 AM, "Zaheduzzaman Sarker via Datatracker" <[email protected] <mailto:[email protected]>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Document: draft-ietf-regext-epp-quic Title: Extensible Provisioning Protocol (EPP) Transport over QUIC Reviewer: Zaheduzzaman Sarker Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC [email protected] <mailto:[email protected]> if you reply to or forward this review. This document is ready but I would suggest to provide clarifications on the following issues - # Issues ## 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>. JG-The goal of the EoQ Connection Start Packet is to bootstrap the EoQ Connection, which uses the QUIC stream, by the server returning the EPP <greeting>. How about changing the "...server to create the QUIC stream." To "...server to initialize the QUIC stream" to clarify that the server is not creating the QUIC stream but initializing it? The next sentence describes exactly what the server does. ## RFC 9000 defines max_ideal_timeout ( https://secure-web.cisco.com/1ysnF2_zMPMLBepN_bAqaSCdfhBRqrIMjJLMRgEtt0CphwAeAZGjYU5PGqSSkm1eMHbWupEeB1pNo38M-vpI6BS3H_O8TXlo3ERdOJzb4WrZT-fRBCVtz1vStVjnpaGVW-hVRhh5XSK8zMSq0zctihbD9bKF1gACy3jTypG5p5sDBvhTD8Dv4fVo5whqkRur1Wv2vk3Ne99yuXixZTMz9NL08dt4N7k2cqjmofTkkeybKtVxpHGI3sycxYUSb86CWEhVfwvgSSPTsWaGEbf2kgb0-qTYp0KpLBpUFwLNYZA4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9000%23idle-timeout <https://secure-web.cisco.com/1ysnF2_zMPMLBepN_bAqaSCdfhBRqrIMjJLMRgEtt0CphwAeAZGjYU5PGqSSkm1eMHbWupEeB1pNo38M-vpI6BS3H_O8TXlo3ERdOJzb4WrZT-fRBCVtz1vStVjnpaGVW-hVRhh5XSK8zMSq0zctihbD9bKF1gACy3jTypG5p5sDBvhTD8Dv4fVo5whqkRur1Wv2vk3Ne99yuXixZTMz9NL08dt4N7k2cqjmofTkkeybKtVxpHGI3sycxYUSb86CWEhVfwvgSSPTsWaGEbf2kgb0-qTYp0KpLBpUFwLNYZA4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9000%23idle-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 does it supposed to work with the max_ideal_timeout if that is negotiated at the connection setup? JG-The idle timeout is handled at the application layer, based on what has been defined for the existing EPP over TCP (EoT) transport in RFC 5734. This language has been modified from the language in Section 2 of RFC 5734, to apply to the hierarchy of the QUIC stream and the underlying QUIC connection. I don't believe for EoQ we want the QUIC connection max_idle_timeout set to a non-zero value, since we don't want the transport-layer to implement an idle timeout that conflicts with the idle timeout implemented at the application-layer at the level of the QUIC stream that represents the EoQ connection. We can add normative guidance to the draft that the max_idle_timeout transport parameter MUST NOT be set to a non-zero value by the client or server. ## 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. JG-The server would implement the SHOULD by at the application-layer based on a configured policy of the number of QUIC streams (EoQ Connection) allowed per QUIC connection. When the QUIC stream limit is reached on a QUIC connection, the server would immediately close a new QUIC stream after receiving the EoQ Connection Start Packet. ## 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? JG-This MUST is added in Section 10.6 to enhance the security of the transport used for an important provisioning application protocol. For EPP, there are a known set of clients that connect to the server, and the provisioning protocol impacts the domain registration industry, so hardening of the transport security is needed. ## QUIC does not have "fragmentation handling", hence it is not clear what is meant by "QUIC fragmentation handling" in section 10.9. JG-Section 14.2 "Path Maximum Transmission Unit" in RFC9000 provides guidance. How about if the last sentence of Section 10.9 in the draft be removed, which currently is " Oversized EPP data units that exceed path MTU require proper QUIC fragmentation handling to maintain transmission reliability."? # 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. JG-How about we update " Sections 2 and 5 of [RFC9000] describe these features, respectively." to "QUIC streams on top of QUIC connections, defined in section 2 and section 5 of [RFC9000], are used to create stateful communications between the client and server."? _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
