BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//Tencent Corporation//Foxmail CALSCALE:GREGORIAN VERSION:2.0 BEGIN:VEVENT UID:6A5E957D-2323-483F-A88E-4A7CFE536402 DTSTAMP:20260506T053125Z CREATED:20260506T053125Z LAST-MODIFIED:20260506T053125Z SUMMARY:Re: AD Review of draft-ietf-regext-epp-quic DESCRIPTION: \n Dear Med\,\n\n Thanks a lot for your kind detail review. \n We authors will read your comments carefully\, provide a response to your comments and update the draft accordingly.\n\nBest Regards\n\n\nJiank ang Yao\n \nFrom: mohamed.boucadair\nDate: 2026-05-05 20:41\nTo: draft-iet f-regext-ep\nCC: [email protected]\nSubject: AD Review of draft-ietf-regext- epp-quic\nHi Jiankang\, Hongtao\, Zhang\, Dan\, and James\, \n \nThank 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 OPSA REA Meeting (*).\n \nYou may find my full review (including all comments\, edits\, nits) of the document at:\n \npdf: https://github.com/boucadair/I ETF-Drafts-Reviews/blob/master/2026/draft-ietf-regext-epp-quic-06-rev%20Me d.pdf \ndoc: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/ 2026/draft-ietf-regext-epp-quic-06-rev%20Med.doc \n \nFWIW\, please find b elow an extract of main comments:\n \n# (generic) Not sure we have the ade quate anchor in the charter for this work. Will discuss this further with the Chairs. \n \n# Are there deployment plans for this transport feature?\ n \n# Be factual\n \nCURRENT:\n leverages the performance and security f eatures of the QUIC protocol\n as an EPP transport.\n \n## On performanc e\n \n### Things are more subtle than that. Please check\, for example\, h ttps://datatracker.ietf.org/meeting/118/materials/slides-118-maprg-sustain ed-throughput-performance-of-quic-implementations \nor https://ieeexplore. ieee.org/document/10060785. There are many studies out there about perform ance.\n \n### Do we have a comparative study under typical EPP deployment conditions to benchmark the options out there?\n \n## On Security: This is mainly based on TLS. Thatâs not specific to QUIC.\n \n# Consider includin g a brief text about the expected transport service (e.g.\, is this mainly about long-lived connection).\n \n# Design approach \n \nThe current desi gn assumes that all commands are sent over the same stream. I wonder wheth er you considered a design where a stream is consumed per command/response exchange (e.g.\, design approach used for DNS over QUIC).\n \nIf that des ign was considered\, can we please have a note about the rationale for pre ferring the current design vs. DoC approach?\n \n# MUST well-known port nu mber\n \nCURRENT:\n server MUST listen for QUIC connection requests on \ n \nI 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 t o:\n \nNEW:\n By default\, an EPP server MUST\n listen for QUIC connec tion requests on a well-known UDP port number assigned\n by IANA (see Se ction 8.1)\, unless there is a mutual agreement to use another port number .\n \n# Unconditional behaviors are problematic\n \nThere are several such constricts in the document that need to be fixed. For example:\n \nCURREN T:\n Once the QUIC connection is established\, the EPP client MUST then \n \nThis assumes that the server has always to accept the connection! Fro m an operational standpoint\, a server may have a policy to rate-limit con nections. This MUST is thus to be revisited.\n \nFor example\, the part ca n be fixed as follows:\n \nOLD:\n The server accepts the QUIC stream\, re ads the EoQ Connection \n \nNEW:\n Absent processing errors or local poli cy\, the server accepts the QUIC stream\, reads the EoQ Connection \n \n# Lack of application-specific errors\n \nCURRENT:\n A client MAY end an\n EoQ session by closing the QUIC stream and the server MUST end the\n EoQ session by closing the QUIC stream.\n \nThis and other similar text ma kes 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\n \n# Consider adding explicit behavior about error handling\ n \nFor example\,\n \nCURRENT:\n Each EPP data unit MUST contain a singl e EPP message. Commands MUST\n be processed independently.\n \nI guess failing to adhere to this MUST will lead to connection closure. Please con sider adding an explicit mention in the document. Also\, how to signal the error to the peer?\n \n# There are many SHOULDs that need to be checked f or compliance with https://datatracker.ietf.org/doc/statement-iesg-stateme nt-on-clarifying-the-use-of-bcp-14-key-words/. \n \nMy edited version incl udes fixes\, but please double check through the document.\n \n# Size and fragmentation\n \nCURRENT:\n 0 1 2 3\n 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\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+\n | Total Length |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+\n | EPP XML Instance |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+\nPlease add a discussion under OPS Considerations S ection about size/MTU and fragmentation. You may refer to rfc9000#section- 14.\n \n# What about other ways to close a connection\n \nDo we need to ne gotiate idle timeout? See\, for example\, the use in 4.4 of RFC9250.\n \n# Missing Operational Considerations Section\n \nAs we are introducing a ne w transport option\, please find below some items (and hints) that I think are worth to discuss:\n \nNEW:\nX. Operational Considerations\n \nX.1. Cl ientâs Fall Back and Management of Multiple Transport\n \n-- See\, for exa mple\, 5.2 of RFC 9250\n \nX.2 Port Reuse\n \nAlthough [RFC5734] does only a request for TCP\, the companion UDP number was also allocated. That pra ctice was prior to [RFC6335] when TCP and UDP port numbers were simultaneo usly assigned when either was requested.\n \nSection 8.2 updates EPP UDP/7 00 allocation to be used for EoQ. This update does not introduce any opera tional issues given that there is no known implementations of EPP over U DP exist.\n \nX.3. QUIC Support Announcement and Discovery\n \n-- Advisory means to know that a server supports QUIC\n \nX.4. Configuration Paramete rs\n \n-- Cover the various configuration parameters/limits\n \nX.5 Diagno stic and Troubleshooting \n \n-- Logging\, specific errors\, etc.\n \nX.6. Address Validation \n \n-- See\, for example\, 5.3 of RFC 9250\n \nX.7. A uthentication Considerations\n \nX.8. 0-RTT and Session Resumption\n \n-- See\, for example\, 5.5.3 of RFC 9250\n \nX.9. MTU and Fragmentation\n \n# Strengthen the language in the security considerations\n \n# Acknowledgem ents and RFC5734\n\nThe text is inspired (and grabs) some portion from RFC 5734. I suggest we add an explicit statement to the Acknowledgements Secti on to ACK that.\n \nLet me know if any clarification is needed.\n \nCheers \,\nMed\n \n(*) https://github.com/IETF-OPS-AD/OPSAREA-meetings/blob/main/ ietf126.md#foo-over-quic-operational-motivations--challenges-per-andersson -20-min \n________________________________________________________________ ____________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confide ntielles ou privilegiees et ne doivent donc pas etre diffuses\, exploites ou copies sans autorisation. Si vous avez re cu ce message par erreur\, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages e lectroniques etant susceptibles d'alteration\, Orange decline toute responsabilite si ce message a ete altere\, deforme o u falsifie. Merci. This message and its attachments may contain confidential or privileged in formation 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 de lete this message and its attachments. As emails may be altered\, Orange is not liable for messages that have bee n modified\, changed or falsified. Thank you.\n ORGANIZER;CN=yaojk:MAILTO:[email protected] ATTENDEE;CN=mohamed.boucadair;ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:mohame [email protected] ATTENDEE;CN=draft-ietf-regext-ep;ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:dra [email protected] ATTENDEE;CN=regext;ROLE=OPT-PARTICIPANT;RSVP=TRUE:MAILTO:[email protected] ATTENDEE;CN=JGould;ROLE=OPT-PARTICIPANT;RSVP=TRUE:MAILTO:[email protected] om DTSTART:20260506T063000Z DTEND:20260506T070000Z LOCATION: PRIORITY:5 CLASS:PUBLIC STATUS:TENTATIVE SEQUENCE:0 X-MICROSOFT-CDO-IMPORTANCE:1 RESOURCES: TRANSP:OPAQUE BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY X-WR-ALARMUID:1DD8021A-6B5B-41D8-8F21-FE33C5E4963B DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
