Hi James, I can only see -02.
I have some feedback. There's not a lot of overlap with what Lucas said. "eoq/0.1" - is this really the string you want. I thought EPP was pretty mature, but this implies the first alpha version. If it were me, I'd use "epp". Start as you intend to finish. "If the QUIC stream is closed after a server receives and successfully processes a command but before the response can be returned to the client, the server MAY attempt to undo the effects of the command to ensure a consistent state between the client and the server." - This is probably quite likely to produce unwanted effects. Don't include this. There's a lot embedded in this "before a response can be returned to a client" part that end up being very tricky. Some people might take that to mean that the server might look for QUIC ACKs to determine if the client has received the information, which is very wrong. In a protocol like EPP, especially one with idempotency, the client needs to be responsible for reliability. Head of line blocking seems like a feature of the protocol. Is there a reason why you didn't go for one exchange per stream, with login on a "control" stream? Does the ordering of commands matter? (To be clear, the answers to these questions belong in the draft, not just in email.) Having to login on every stream seems unnecessary. Similarly, it's unclear to me what the value of <logout> is if the login is bound to a stream. I can't see why you need to complete a logout transaction as opposed to closing a stream. "A server SHOULD impose a limit on the amount of time required for a client to issue a well-formed EPP command " - Is this globally, or per-stream? The field definitions in Section 5 are garbled. I found the definition of the connection start hard to understand. I *think* that you are saying that the literal string "EoQ Connection Start" is sent instead of XML. I have to ask: why? Section 7 seems to describe features of QUIC, rather than features of EoQ. Consider trimming it to those things that are important for EoQ functioning. On Tue, Feb 3, 2026, at 07:49, Gould, James wrote: > Lucas, > > draft-ietf-regext-epp-quic-03 was just posted to incorporate some nit > fixes. Please review and let us know whether your feedback has been > addressed. > > 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>
