Hello Gorry,
Thanks for your kind comments. Some responses inline below.
> 2026年6月28日 04:24，Gorry Fairhurst via Datatracker <[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.
> 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>].."
> ----------------------------------------------------------------------
> 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.
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. :)
Thanks a lot.
Jiankang Yao
>
> 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]
