Lucas, Thank you so much for your valuable feedback. The EoQ editors will review your feedback in detail and provide a response with the actions taken. From a high-level your feedback will help to tighten the language of the draft and open opportunities for clarity.
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 * 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. * 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] * 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. * 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 * 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] * 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. * 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. * 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>
