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]>
写道：
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]
To unsubscribe send an email to [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]
