Hi Jiankang, Hongtao, Zhang, Dan, and James, Thank you for the effort put into this specification. FYI, this is even timely as we are planning to have a dedicated slot on such uses during IETF#126 OPSAREA Meeting (*).
You may find my full review (including all comments, edits, nits) of the document at: * pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2026/draft-ietf-regext-epp-quic-06-rev%20Med.pdf * doc: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2026/draft-ietf-regext-epp-quic-06-rev%20Med.doc FWIW, please find below an extract of main comments: # (generic) Not sure we have the adequate anchor in the charter for this work. Will discuss this further with the Chairs. # Are there deployment plans for this transport feature? # Be factual CURRENT: leverages the performance and security features of the QUIC protocol as an EPP transport. ## On performance ### Things are more subtle than that. Please check, for example, https://datatracker.ietf.org/meeting/118/materials/slides-118-maprg-sustained-throughput-performance-of-quic-implementations or https://ieeexplore.ieee.org/document/10060785. There are many studies out there about performance. ### Do we have a comparative study under typical EPP deployment conditions to benchmark the options out there? ## On Security: This is mainly based on TLS. That's not specific to QUIC. # Consider including a brief text about the expected transport service (e.g., is this mainly about long-lived connection). # Design approach The current design assumes that all commands are sent over the same stream. I wonder whether you considered a design where a stream is consumed per command/response exchange (e.g., design approach used for DNS over QUIC). If that design was considered, can we please have a note about the rationale for preferring the current design vs. DoC approach? # MUST well-known port number CURRENT: server MUST listen for QUIC connection requests on I know this is inherited from the TCP mapping spec, however, I don't think this is great from an operational standpoint. I suggest to update to: NEW: By default, an EPP server MUST listen for QUIC connection requests on a well-known UDP port number assigned by IANA (see Section 8.1), unless there is a mutual agreement to use another port number. # Unconditional behaviors are problematic There are several such constricts in the document that need to be fixed. For example: CURRENT: Once the QUIC connection is established, the EPP client MUST then This assumes that the server has always to accept the connection! From an operational standpoint, a server may have a policy to rate-limit connections. This MUST is thus to be revisited. For example, the part can be fixed as follows: OLD: The server accepts the QUIC stream, reads the EoQ Connection NEW: Absent processing errors or local policy, the server accepts the QUIC stream, reads the EoQ Connection # Lack of application-specific errors CURRENT: A client MAY end an EoQ session by closing the QUIC stream and the server MUST end the EoQ session by closing the QUIC stream. This and other similar text makes it difficult at the remote side to diagnostic the error cause. I think that having specific error messages to ease diagnostic would be helpful. See, for example, https://datatracker.ietf.org/doc/html/rfc9250#name-doq-error-codes # Consider adding explicit behavior about error handling For example, CURRENT: Each EPP data unit MUST contain a single EPP message. Commands MUST be processed independently. I guess failing to adhere to this MUST will lead to connection closure. Please consider adding an explicit mention in the document. Also, how to signal the error to the peer? # There are many SHOULDs that need to be checked for compliance with https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/. My edited version includes fixes, but please double check through the document. # Size and fragmentation CURRENT: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EPP XML Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Please add a discussion under OPS Considerations Section about size/MTU and fragmentation. You may refer to rfc9000#section-14. # What about other ways to close a connection Do we need to negotiate idle timeout? See, for example, the use in 4.4 of RFC9250. # Missing Operational Considerations Section As we are introducing a new transport option, please find below some items (and hints) that I think are worth to discuss: NEW: X. Operational Considerations X.1. Client's Fall Back and Management of Multiple Transport -- See, for example, 5.2 of RFC 9250 X.2 Port Reuse Although [RFC5734] does only a request for TCP, the companion UDP number was also allocated. That practice was prior to [RFC6335] when TCP and UDP port numbers were simultaneously assigned when either was requested. Section 8.2 updates EPP UDP/700 allocation to be used for EoQ. This update does not introduce any operational issues given that there is no known implementations of EPP over UDP exist. X.3. QUIC Support Announcement and Discovery -- Advisory means to know that a server supports QUIC X.4. Configuration Parameters -- Cover the various configuration parameters/limits X.5 Diagnostic and Troubleshooting -- Logging, specific errors, etc. X.6. Address Validation -- See, for example, 5.3 of RFC 9250 X.7. Authentication Considerations X.8. 0-RTT and Session Resumption -- See, for example, 5.5.3 of RFC 9250 X.9. MTU and Fragmentation # Strengthen the language in the security considerations # Acknowledgements and RFC5734 The text is inspired (and grabs) some portion from RFC5734. I suggest we add an explicit statement to the Acknowledgements Section to ACK that. Let me know if any clarification is needed. Cheers, Med (*) https://github.com/IETF-OPS-AD/OPSAREA-meetings/blob/main/ietf126.md#foo-over-quic-operational-motivations--challenges-per-andersson-20-min ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
