On 27/06/2026 22:43, Gorry Fairhurst via Datatracker wrote:
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. - 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?
## Please consider and respond to Zahed's review comment:
RFC 9000 defines max_ideal_timeout (
https://datatracker.ietf.org/doc/html/rfc9000#idle-timeout ), section 3 of this
draft does not relate to usage of that max_ideal_timeout but states -"the
server MAY end the QUIC connection immediately". How is it supposed to work
with the max_ideal_timeout if that is negotiated at the connection setup?
## Section 4 says -
A server SHOULD limit a client to a maximum number of QUIC streams per
QUIC connection based on server capabilities and operational load.
How do you do that via RFC9000? Or is this something new? If you are using
RFC9000, then add a reference to the concurrency control described in
RFC9000. or explain how your intent to enforce the SHOULD.
## Section 10.6 says -
EoQ servers MUST utilize the QUIC Retry Packet mechanism described in
Section 8.1.2 of [RFC9000].
As RFC9000 does not apply MUST to use QUIC Retry Packets for address
validation, what is the justification for the MUST here?
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you for submitting this document, I have the following (non-blocking)
comments:
## 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.
## 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.
# Please address the issues raised by Zahed as a part of his TSVART review:
## Even though section 3 explains it the correct way, in section 6, it says -
The EoQ Connection Start Packet is written by the client after creating
a QUIC stream to signal to the server to create the QUIC stream.
This is inaccurate when client-initiated bi-directional streams are used. The
server does not create streams; it just uses the streams created by the
client. The snipped emphasizes that "signal to the server to create stream "
that needs to be fixed. If there are no specific explanations, then it would
suggest to rewrite the sentence to --
The EoQ Connection Start Packet is sent by the client after creating a
QUIC connection to signal to the server, on the client-initiated stream,
respond with EPP<greeting>.
# Nits -
- Section 7 : the references to RFC9000 are out of order in the description of
"Stateful Nature". RFC 9000 section 2 is about streams and section 5 is about
connections.
Best wishes,
Gorry
Following-up on my ballot position, here are a few more details which
help explain what I do not understand from the document and what might
be useful to include based on the current revision:
(1a) MTU: Section 8.9: There is no MTU guidance in QUIC. QUIC does not
configure layer 2 - quite the opposite QUIC enforces a minimum packet
size (and hence requires a minimum PMTU) and the connection fails when
not supported. QUIC provides a method to increase the packet size.
(1b) Fragmentation: QUIC requires that packets are not fragmented at the
IP layer. The last sentence of Section 8.9, seems to be confused, and
simply ought to restate the QUIC requirement.
--
(2) Section 4 says:
A server SHOULD limit a client to a maximum number of QUIC
streams per
QUIC connection based on server capabilities and operational load.
How do you do that via RFC9000? Or is this something new? If you are
using
RFC9000, then add a reference to the concurrency control described in
RFC9000. or explain how your intent to enforce the SHOULD.
- Can more be explained? For me, this lacks a real explanation of the
goal and the protocol mechanisms that will be used. At the end of
Section 7, does this result in a protocol violation, and hence a close
of the QUIC connection or the QUIC stream? and Why?
- Could you please specify a default value?
--
(3) As RFC9000 does not apply MUST to use QUIC Retry Packets for
address validation, what is the justification for the MUST here?
*Sorry, I see the first text I mentioned was removed in the latest rev.,
but for me it still leaves something missing:
I do suggest though that the document clarifies that this is a reliable
stream, and hence there is retransmission of missing frames in a QUIC
stream, possibly in the first sentence of Section 4, but maybe also earlier?
--
(4) I see the design SHOULD close a QUIC Stream on error, but keeps the
QUIC connection to the endpoint open. Why not close the connection,
rather than request the stream to be closed? (i.e. explain).
--
Below are COMMENTS for which I am hoping to understand the context, and
preferably for the document to explain:
--
(4) 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.
(4a) The document states this can be done over UDP, so it can be done
over QUIC. I agree - but why must it be done? ... what are the features
of QUIC that motivated this work -- besides offering another choice
(which I'd argue is very bad).
(4b) I note from the shepherd writeup there is no implementation of the
latest draft and "At the time of composing this document no public plans
to deploy this transport were found."
I question why there is no explanation why the iETF did this work,
especially why this is PS? Please add an explanation of the "benefits"
of using QUIC for this service - aside from just session resumption.
--
(5)
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.
- Please suggest updated text for Section 11 that are consistent with
those of QUIC.
--
(6)
The current text to me still seems weird:
"EoQ Connection Start Packet: Used by clients to complete the
creation of an EoQ connection by signaling the server to create
the QUIC stream and return the EPP <greeting> needed for an EPP
connection. Section 6 formally defines the EoQ Connection Start
Packet."
- Is it there is a setup the connection in QUIC and then setup a stream,
and then exchange this EoQ setup?
- If not what happens? Please explain?
- I also do not understand really how this relates to multi-streaming,
the document appears to be missing a fundamental part of the protocol
mapping on what happens if there is a connection to the current endpoint.
--
(7)
I see there was new text:
"The max_idle_timeout transport parameter defined in
Section 18.2 of [RFC9000] MUST NOT be set to a non-zero value
by the
client or server. .
- But I do not understand how this works for multistreaming, and sending
a QUIC FRAME for keep alive is a good idea, rather than using a
connection-based keep-alive in QUIC that has the standard protocol
properties?
- How might this interact with flow/congestion control when sent as data
in a QUIC FRAME?
- What happens when there are multiple streams active?
--
(8)
I see there was new text:
"Once the last QUIC stream for a QUIC connection is closed, the server
MAY end the QUIC connection immediately."
- What happens when there are multiple streams active, does the first
stream closed close the connection and all other streams?
- Why is this the case?
I do hope this email starts a discussion that results in a clearer
specification. I would also be happy for Zahed to continue in responding
to any questions that might arise from the TSVART Review (and have
copied him in cc to this email).
Best wishes,
Gorry
(WIT AD)
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
