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] 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>. ## 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 does 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? ## QUIC does not have "fragmentation handling", hence it is not clear what is meant by "QUIC fragmentation handling" in section 10.9. # 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. _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
