Thanks for the work on this draft.

Seeing all the helpful points already raised by others in their reviews, the only additional comment I have is with respect to the reuse of port 700.

I see the WG discussed and reached consensus to reassign the reference for UDP port 700 to the EPP-over-QUIC specification rather than assign a new port number, citing the absence of any known legacy UDP implementations. In order to safely accommodate any implementation that may exist now or in the future, it might be helpful to add a reference to RFC 9443 and mention that this mechanism can be used to demultiplex EPP over UDP from EPP over QUIC.

Thanks to Mike O. for the SECDIR review.

Thanks for the well written draft.

* Please consider protections against excessively long messages as noted in Mike's SECDIR review.

* Is a “MUST” with an “unless” really a MUST?
Section 3 ¶2: `By default, an EPP server MUST listen for QUIC connection requests on a well-known UDP port number assigned by IANA (see Section 9.2), unless there is a mutual agreement to use another port number.`

* I will echo the comment of other ADs - I'm not sure what the support of multiple QUIC streams does or why its useful; parallel processing on the EPP server maybe?

* Most of my other comments are already covered by other ADs.

# Éric Vyncke INT AD comments for draft-ietf-regext-epp-quic-10
CC @evyncke

Thank you for the work put into this document.

Special thanks to Med Boucadair, the responsible AD, to point me to the last paragraph of section 7 (which could use a MUST though) to handle my previously [DISCUSS ballot](https://mailarchive.ietf.org/arch/msg/regext/4zJiC7I3GlGPdjPuVqXi5smwYpQ/)

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## COMMENTS (non-blocking)

### Gorry's DISCUSS

I second Gorry's DISCUSS issues as they are sensible

### Why QUIC in Section 1

I failed to find why using QUIC is useful, especially with `EPP sessions use a single QUIC stream for all command and response exchanges` especially when reading section 3 `This means that a single QUIC connection may support multiple EoQ sessions.` The introduction should probably state that there could be several EPP sessions (for different domains ?) over a single QUIC connection.

### Section 3

`As shown in Figure 1 in Section 4,` it is painful for the reader to scroll down. Suggest moving the figure in section 3.

s/on a well-known UDP port number assigned by IANA/on *the* well-known UDP port number assigned by IANA/ (if there is only one)

### Section 4

Why not a "MUST" in `Absent local policy, a server SHOULD end an EoQ session and close the QUIC stream if a well-formed command is not received within the time limit` ?

Also note https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ (and thanks for the guidance provided for previous "SHOULD")

### Section 5

s/The 32 bits total length/The *32-bit* total length/

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

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. 
GF: DONE in rev -12

## 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.
GF: DONE in rev -12

# 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>.
GF: DONE in rev -12

# 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.
GF: DONE in rev -12

I thank you for addressing my discussion topics in rev -12.
Best wishes,
Gorry

No Routing associated observations

Thank you to Joel Halpern for the GENART review.