Hi Gorry and all, Thanks. New version is ready. URL: https://www.ietf.org/archive/id/draft-ietf-regext-epp-quic-11.txt Status: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-quic/ HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-quic Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-quic-11
I hope that this version addresses all concerns. Best Regards Jiankang > 2026年7月2日 00:40，Gorry Fairhurst <[email protected]> 写道： > > On 01/07/2026 18:33, Jiankang Yao wrote: >> Hello Gorry, >> >> Thanks for your kind comments. Some responses inline below. >> >>> 2026年6月28日 04:24，Gorry Fairhurst via Datatracker <[email protected]> >>> <mailto:[email protected]> 写道： >>> >>> 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. - >> >> >> Section 14 of RFC 9000 says “QUIC MUST NOT be used if the network path >> cannot support a maximum datagram size of at least 1200 bytes.”. >> >> "UDP datagrams MUST NOT be fragmented at the IP layer. In IPv4 [IPv4 >> <https://www.rfc-editor.org/rfc/rfc9000.html#IPv4>], the Don't Fragment (DF) >> bit MUST be set if possible, to prevent fragmentation on the path.” >> >> So here just emphasised that network paths are ok for EPP over QUIC to be >> used. >> > This is all true, but you may like to exactly quote the RFC9000 words in the > spec., to avoid trying to paraphrase them. >> >>> 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? >>> >>> >> >> Actually, the main idea is just to follow Section 14 of RFC 9000 for EPP >> message delivery. >> >> How about, >> >> Old: >> >> “EoQ implementations MUST follow the MTU and fragmentation guidance defined >> in [RFC9000 >> <https://www.ietf.org/archive/id/draft-ietf-regext-epp-quic-10.html#RFC9000>]. >> Operators are encouraged to provision network paths with appropriate MTU >> sizes to avoid packet fragmentation for EPP message delivery." >> >> >> New: >> >> "EoQ implementations MUST follow Section 14 of RFC9000 [RFC9000 >> <https://www.ietf.org/archive/id/draft-ietf-regext-epp-quic-10.html#RFC9000>].." >> >> > Exactly, this would be be fine. >> >> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Thank you for submitting this document, I have the following comments: >>> >>> (1) 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. >> >> >> >> EPP is primarily deployed for communication between domain registries and >> registrars, which commonly run dozens to hundreds of concurrent EPP sessions. >> Traditional EPP-over-TCP (EoT) requires a dedicated TCP connection for >> every single EPP session, resulting in substantial connection overhead and >> resource consumption. >> EoQ addresses this issue by leveraging QUIC stream multiplexing: multiple >> independent EPP sessions can run over one single persistent QUIC connection. > That seems a good case, to me, please these points into an early part of the > document to explain. >> >> >> EoQ provides registries and registrars with an additional flexible transport >> option. >> >> >> >>> >>> (2) 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. >> >> >> Maybe, this is another reason that we use EoQ. :) > Yes, that would also be good, but you need to state that in the I-D. > > And be careful in the security considerations that you refer to RFC9000's > security considerations to avoid paraphrasing RFC9000. > >> >> Thanks a lot. >> >> Jiankang Yao >>> >>> Best wishes, >>> Gorry >>> >>> >>> >>> _______________________________________________ >>> regext mailing list -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> >> > I'll review the revised I-D when published, but if you wish to sen specific > proposed text I can also read that ahead of making a new revision, > > Best wishes, > > Gorry > > _______________________________________________ > regext mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
