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
[2] - https://www.ietf.org/archive/id/draft-ietf-quic-http-27.html#section-3.1
[3] -
https://datatracker.ietf.org/doc/html/rfc9000#name-variable-length-integer-enc
[4] - https://www.rfc-editor.org/rfc/rfc9308.html#name-flow-control-deadlocks
[5] - https://www.rfc-editor.org/rfc/rfc9308.html#name-error-handling
[6] - https://www.rfc-editor.org/rfc/rfc9250.html#section-8.4
