Lucas, Sorry for the long delay in a response to your valuable feedback. I include the responses embedded below prefixed with “JG-“. Based on your feedback, expect to see updates made in draft-ietf-regext-epp-quic-02.
Thanks, -- JG [cid87442*[email protected]] James Gould Fellow Engineer [email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Lucas Pardue <[email protected]> Date: Wednesday, September 17, 2025 at 3:36 AM To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] [regext] Review of Extensible Provisioning Protocol (EPP) Transport over QUIC draft-ietf-regext-epp-quic Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi folks, (Including the regext and quic mailing lists for visibility) The REGEXT WG adopted draft-ietf-regext-epp-quic earlier this year and asked for some feedback. The overall use of QUIC seems good. As an individual, I've collected some, what I believe, fairly general comments about application protocol mapping documents that I figured would be good to share with the broader community of protocol designers. * Section 1 and 3 mention of TLS Seems to spend a litte too many words mentioning TLS, which is not an important detail for this draft. Its enough to say that QUIC connections are always secure and the details of establishing a conneciton are provided in Section 5 of RFC 9000 JG–The reason for this is that for EPP, TLS via EPP over TCP RFC 5734, has been the only transport defined. Providing more associated to the use of TLS is important for those familiar with EoT in bridging to EoQ. * Section 3 terms and general layout The layout here might be improved to follow the order of how a connection is established. I'm not familiar with EPP but the mixing of QUIC connections, EoQ connection and EoQ session doesn't appear completely clear to me. It would probably help to define the terms more upfront. For example, import RFC 9000's definition of client, server and connection. State explicitly that the connection handshake establishes the EPP over QUIC (EoQ) protocol via ALPN. That the EPP client is a QUIC client, and the EPP server is a QUIC server. Make it clearer earlier that whatever you want to call the EPP over QUIC connection, also allows for multiple EoQ connections and EoQ sessions, which are bound to client-initiated bidirectional streams. JG-Thanks, we’ll look to help clarify the terms earlier with a Terms and Definitions section like Section 1.2 of RFC 90000. . * General - versioning Given that you are relying on ALPN for negotiation, I recommend adding versioning to it while you iterate on the I-Ds. For example keep the "eoq" identifier purely for the published RFC, and in the meantime use "eoq-01" to indicate a specific draft version that is an interop target. This will allow you to change the protocol design and avoid breaking extant deployments. See early HTTP/3 draft example text if you want to take this approach [2] JG-I like the use of the point versioning up until the draft passes WGLC. The model that we’ve used for EPP XML namespaces in some of the EPP drafts is to use point versioning. An example is the Registry Fee Extension in draft-ietf-regext-epp-fees-09 that had the XML namespace “ietf:params:xml:ns:fee-0.25” that was bumped to “ietf:params:xml:ns:fee-1.0” when the draft passed WGLC and stayed that way when published as RFC 8748. We didn’t have the point versioning match the version of the draft, where we only bumped the version number when there was a material change to the draft, since there can be many non-material draft updates. The IANA considerations section will make it clear which ALPN value applies. I don’t see a character limitation, so would it make sense to use a ‘/’ as a separator to match other application protocols, such as using “eoq/0.1” to start that would eventually become “eoq/1.0” when passing WGLC? * Section 3 stream states and session lifecyle I suspect this will need to be expanded a bit in time. I'm not familiar with EPP but bidirectional QUIC streams have send and receive states [1], which means that you may encounter edge cases that the spec does not currently account for. For example, a client that send a FIN flag causes the stream to be half closed, does a server have to immediately terminate its side in this case. JG-The EPP connection management is handled in RFC 5730 based on the state machine in section 2 “Protocol Description”. It doesn’t explicitly state that the server terminates the connection when the client closes the connection, but that’s a common server practice. Defining QUIC as a transport, requires us to map the QUIC connection and streams to the associated EPP connections and sessions to leverage the existing language in RFC 5730. We will extend the sentence “A client MAY end an EoQ session by closing the QUIC stream” to “A client MAY end an EoQ session by closing the QUIC stream and the server MUST end the EoQ session by closing the QUIC stream.” * Section 3 and 6 stream creation These sections use terms of art that aren't really used by QUIC. It would be better to be explicit that the client uses a client-initiated bidirectional stream, and the client's send side MUST begin with an EoQ Connection Start Packet. You don't need to state things like "creating a QUIC stream to signal the server to create the QUIC stream". You should state what happens in the failure mode that a stream does not begin with the correct packet or greeting. The phrase "Once the EPP server accepts the QUIC stream" is odd in the context it is used. The client has sent data that the server would already have permitted via stream count and flow control limits. It would be clearer to say something like "Once the EoQ Connection Start Packet is read by the server ...". If might help to use QUIC notation here, see below JG-We can make it clear that the client uses a client-initiated bidirectional stream in section 3. The reference to “creating a QUIC stream to signal the server to create the QUIC stream” is used on section 6 to define the purpose of EoQ Connection Start Packet. Without the client writing the EoQ Connection Start Packet, the server will not be signaled to create the stream and will not return the EPP <greeting> to bootstrap the EPP connection. The establishment of the connection and the returning of the EPP greeting is a requirement in the base EPP RFC 5730, so without the server receiving the signal there is no ability to comply with RFC 5730. Do you have a better way of stating the purpose of having the client writing to the QUIC stream to trigger the server to establish the QUIC stream and return the EPP< greeting>? JG-For “Once the EPP server accepts the QUIC stream” is there the concept of accepting the peer-initiated stream, since the input and output streams are not created for the application protocol until a QUIC stream is created and accepted by the peer? In implementing EoQ, I used Kwik with the interface https://github.com/ptrd/kwik/blob/master/core/src/main/java/tech/kwik/core/server/ApplicationProtocolConnection.java that uses the term accept for a peer-initiated stream. The EoQ Connection Start Packet is not read until the stream is accepted by the peer, which in the case of a Kwik server is the implementation of the ApplicationProtocolConnection.acceptPeerInitiatedStream(QuicStream) method. Does the QUIC protocol have a better term of accepting the peer-initiated stream? * Section 5 data unit format I'm not sure if this is inherited from EPP itself but you could consider a slighlty different format. This is just a suggestion, useful if you send small messages frequently and want to save bytes. If EPP benefits from 32-bit alignment feel free to ignore this. Note however that there is no guarantee that the bytes of QUIC streams will be presented at any such boundaries. For instance, using QUIC variable-length integers (varint [3]), you don't need a fixed size for each message length. Using QUIC notation, something like below would be consistent with how QUIC and serveral other application mappings documents do things ``` EPP Data Unit Format { Length (i), EPP XML Instance (..), } Length: A variable-length integer that describes the length in bytes of the EPP XML Instance. EPP XML Instance: The EPP XML instance carried in the data unit. ``` Since QUIC varint lengths are self-describing, the length field can simply be the actual payload-length. You can also apply additional restrictions on the size if the varint max is too big for your use case. Using this approach, your EoQ Connection Start Packet definition then becomes ``` EoQ Connection Start Packet { Length (i) = 20, Payload = "EoQ Connection Start" } ``` saving 3 bytes if encoded in a 1-byte length varint. If you expect large messages, pay due considerations to RFC 9308 Section 4.4 [4] JG-Yes, the 4-byte network header is inherited from EoT in RFC 5734. I believe that it’s best to match the packet framing approach taken in EoT for EoQ. * Error handling of partial messages or corrupted streams Probably more of an EPP thing that QUIC but its not clear to me what happens if the EPP XML Instance is truncated. For example if the length was invalid. Similarly, if something does go wrong on a stream, the chances are the whole thing becomes corrupted. Consider any stream reading error as terminal for the stream or even the connection. JG-That’s handled by EPP, where a partial packet would result in closing the EoQ session and subsequently the QUIC stream. * Describe how the other 3 stream types are/are not used QUIC provides 4 stream types and you're using 1. Consider how you want to spell out what it means if an endpoint opens a stream of you don't define. Is it quietly ignored (so you can define some future extension), is it a protocol error and the connection should be closed? Etc. JG-I believe we can be explicit and specify that EoQ supports only the client-initiated, bidirectional stream type. The EPP transports must support bidirectional streams to satisfy the EPP Server State Machine in RFC 5730. * Lack of application-level error codes See RFC 9308 for more details [5] but generally speaking, you have not defined any application-level error codes. There appear to be several avenues for sending CONNECTION_CLOSE, STOP_SENDING or RESET_STREAM frames that are triggered by the EPP application. It would be good to define a small number of application-level codes here to let you differentiate between closed no error, implementation error, or protocol errors. It is good practice to also define an IANA registry for these. DNS over QUIC is a good example you can draw inspiration from [6] [1] - https://datatracker.ietf.org/doc/html/rfc9000#name-stream-states<https://secure-web.cisco.com/1yj3u9wqg5AQAYMnKAb3paB05hTjb0HyeGt4Y-d-oOLQR62IwmBAnmTNv3eui0oRHjpJ6zvD9K8CiBCYDl5_CNFr24EmPD5sQ2Jb3Ga_oBa9yW9_SKLf2Xo2HJwy-6-RmWpOGZciL_2ccLd9qYSUPl69Z_IXfBzRYszYJm2r7UVkJNuIHXMCodmQZ7yhzscYgtiQ38B5wAwVx0Na-dRxtZwf1nb0rJ1YGljPB-vZvQiaQY2BzGEC8FeKgzIZ8Xx3TmsZjGTEYuwCXnGShzm8TURuUM7F9frjGBkOVZzn4kaY/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9000%23name-stream-states> [2] - https://www.ietf.org/archive/id/draft-ietf-quic-http-27.html#section-3.1<https://secure-web.cisco.com/1N0U599NoLbUG387yyzaj1NYmEchtNt-wNt5y35MWNnj6NFmminx24HXRYEH9NirLimOgLsDLiFP0CeQoyv37jKBA7wYlDQtoV6O507X_4nmnIidvhfqEZTqK-r-m5_D9yVNyysaLyVWGW5f_h9HmNPKVmveXw0x3v1R0AnA6kPb3Flfg4UEdL_DsEcaiqNEtsG1sMUarmZ5QCu2UUkgMzpO8Pyuk2_F27MdfBbj1GXtTQTP9d9krjnJD5uEqUDRLtT4FQS9Qq0aIFQCwMJmls1WPvVkAXaqajCEq7urO54o/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-quic-http-27.html%23section-3.1> [3] - https://datatracker.ietf.org/doc/html/rfc9000#name-variable-length-integer-enc<https://secure-web.cisco.com/1-zJ-SyIThd8X4IbY26s1O3CeMnjHHqYpb7aIcWk7hlViiSjZNT_aBo3ePRE10LcvSj_P3JfmS-MeXgqZVFlC1O11LfTPDUpXr9iAlJi3p7WURScvSecAQCsz8iWvUbhDi-1hf9EvbkngZiqx6z3pIr6YUCt0klugEP5Fzcx0dJWy68fMqcs6jGYU7o1DksBHHFK5fqSmt9HkjKmqshV-PRFAzhTz-XOnXLoa2dtfH89j6yMlIJJuE9-0xZd2iUvHGnDH6vT1sF8npi-XQN4aeoCdZE-Mm9THewblXnNG7nQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9000%23name-variable-length-integer-enc> [4] - https://www.rfc-editor.org/rfc/rfc9308.html#name-flow-control-deadlocks<https://secure-web.cisco.com/1s2e1r9ogOeTKgJwcwBF-xUVzOy0s5YoGKcu0AYldiweA2EUnjCUf-teheKlhylJgx7IBgVCI-OCGJTjW7ZuyaA0UngrPm-7eqM4XFm1vRw_o53PyQlDVz8_we_tFtCGdDI6kiEPQHTOG_x-xR3CdFtaKrWhsmKrZ7NRPamBk5QiV6eoF2k258_bm4lH61SK48XQYPVexj5ufkDZt6CEF15bBDLdrfna0MJbm9Cs32c-Q-PMVl6FcDEmAbXa7-wpbsuEVZxVQAx8PZGphKg6_qfb5PRWwDpUB6pgyQKpgypk/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9308.html%23name-flow-control-deadlocks> [5] - https://www.rfc-editor.org/rfc/rfc9308.html#name-error-handling<https://secure-web.cisco.com/1FHOX6L3U82jENRF9dAzqcAYA_IiU6gUh87_Juie-8_i8GhGj9vNbLlwb-yewD90w52GCbeYWoQewT7THap6wr3wK3i9rStqk7SldhcclUb8AqjDs6Chi31JuMe4UeIiklLYvyn1MeHS-P6zOcwLUOfewSx_E6yGXZl7jQPhPU5X69dHdqhNSW-orF3QA2bSKTYX8wEb4NuBoMKaSZ_I3-htS0vCV7_mhx1fQvBwdSRwKIR2BYZymlui84VC5ll9ttHcWFtKqjqRORP4UGY6ZwwJlpj935eUgy_r_l1s13cE/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9308.html%23name-error-handling> [6] - https://www.rfc-editor.org/rfc/rfc9250.html#section-8.4<https://secure-web.cisco.com/1tqTF1JpRPiozz7qdt0n5xEgSWfOPJ0Xowj8eCW-FQeOk26Are_IB37J6kpkWWHqJJBGm_DQwTkfcnuDBqrc8PIwNt4nU4eM2J2qRxF4QK1M76pjLaopNrZmNwZDH8h8rjKqR4zqC6hrxL1eDzvS4le1Z-M8mEUssntvL3aTwvLvMBB8Y95mrZ8DMYwNxbnZRHojvri0E6EueiZeLGvir77A3ALoQvPK2dDTX7D3KtWrKatRL2J9NBDmEcTpz-jSyJcPHufoG0GKNYBiiGPWj6nkqN6FRL0LhT9UWDXY5Wog/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9250.html%23section-8.4> JG-We are limited to the set of EPP error codes defined in Section 3 “Result Codes” in RFC 5730 and since EoQ is a pluggable transport we need to map any transport errors using the application protocol list of result codes. We’ll look at the examples that you’ve provided to be explicit with the mapping of the QUIC error codes to the EPP application protocol result codes.
