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

Section 5, Data Unit Format:

305 >    The EPP data unit contains two fields: a 32-bit header that describes
306 >    the total length of the data unit, and the EPP XML instance.  The
307 >    length of the EPP XML instance is determined by subtracting four
308 >    octets from the total length of the data unit.  A receiver must
309 >    successfully read that many octets to retrieve the complete EPP XML
310 >    instance before processing the EPP message.

The 32-bit Total Length field permits a declared length of up to
approximately 4 GB.  The SECDIR review (thanks, Mike) against -09 raised this concern.
RFC 5734 is equally silent on length-field bounds checking for the
identical framing it defines.  In my opinion, the Security
Considerations section should recommend that
implementations validate the declared length against a locally
configured maximum before allocating memory or attempting to read the
declared number of octets.  Without such guidance, a single crafted
packet with an oversized length field can exhaust a receiver's memory.
I would suggest adding a sentence to Section 11 to this effect.

---

Section 6, EoQ Connection Start Packet, error handling:

337 >    Absent processing errors or local policy, the server accepts the
338 >    QUIC stream, reads the EoQ Connection Start Packet, and returns
339 >    the EPP <greeting> to the client on same QUIC stream.

The document specifies that a valid EoQ Connection Start Packet MUST be
exactly 24 octets containing the literal string "EoQ Connection Start"
(Section 6).  However, it does not specify what the server MUST or
SHOULD do if it receives a stream-opening packet that does not conform
to this format — for example, if the Total Length field is not 24, or
if the payload does not match the expected constant.  Section 7
addresses error handling for malformed EPP commands, but not for a
malformed EoQ Connection Start Packet.  In my opinion, the document
should specify the required server behavior in this case (e.g., close
the QUIC stream, with or without returning an error).

---

Section 4, Message Exchange, stream limiting:

229 >    A server SHOULD limit a client to a maximum number of QUIC
230 >    streams per QUIC connection based on server capabilities and
231 >    operational load.  Absent such limit, a server may be subject to
232 >    overload and resource exhaustion.

RFC 9000 Section 4.6 defines the normative QUIC mechanism for this:
servers use the max_streams transport parameter and MAX_STREAMS frames
to limit the number of streams a peer may open, and endpoints MUST NOT
exceed the limit set by their peer.  In my opinion, this section should
reference that mechanism explicitly, so that implementers understand
both how to enforce the limit and the QUIC-level error (STREAM_LIMIT_ERROR)
that results from a client exceeding it.  The TSV-ART review against
-09 also noted this gap.

---

Section 3, Session Management, max_idle_timeout:

207 >    The max_idle_timeout transport parameter defined in
208 >    Section 18.2 of [RFC9000] MUST NOT be set to a non-zero value by the
209 >    client or server.  Once the last QUIC stream for a QUIC connection is
210 >    closed, the server MAY end the QUIC connection immediately.

I understand the intent. However, a consequence of setting max_idle_timeout to 0 is that a
QUIC connection with no open streams can remain open indefinitely.
The server is permitted but not required to close the connection when
the last stream closes.  In my opinion, the document should say
something about the expected behavior in this state, perhaps elevating
the "MAY end the QUIC connection immediately" to SHOULD, to help
operators avoid accumulating zombie connections.

---

Section 9.2, Registration of Port Number:

511 >    This document requests IANA to update that entry so that it is
512 >    reassigned to EPP and add a reference to this document.

The phrase "reassigned to EPP" is confusing because port 700/UDP is
already assigned to the EPP service (service name "epp").  What the
document is requesting is an update to the Description field (from the
current generic EPP text to "EPP run over QUIC") and the addition of
this RFC as an additional reference alongside [RFC5734].  
The IANA request should be stated precisely: for example,
"This document requests IANA to update the Description field of the
EPP UDP/700 entry to 'EPP run over QUIC' and to add this document as
an additional Reference alongside [RFC5734]."