IETF Last Call Review of draft-ietf-regext-epp-quic-09
review-ietf-regext-epp-quic-09-tsvart-lc-sarker-2026-06-15-00

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

This document is ready but I would suggest to provide clarifications on the
following issues -

# Issues
## 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>.

## 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 does 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?

## QUIC does not have "fragmentation handling", hence it is not clear what is
meant by "QUIC fragmentation handling" in section 10.9.

# 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.