[regext] Éric Vyncke's Discuss on draft-ietf-regext-epp-quic-10: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-regext-epp-quic-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-quic/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke INT AD comments for draft-ietf-regext-epp-quic-10
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (trivial to address), some
non-blocking COMMENT points/nits (replies would be appreciated even if only for
my own education).

Special thanks to  for the shepherd's detailed write-up including the WG
consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of
https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by
a tool to create github issues.

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Section 6

Please state the expected behavior of the EPP server when `The length of a
valid data unit MUST be 24 octets` is not correct, even if somehow obvious, it
should be stated in a PS.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


## COMMENTS (non-blocking)

### Gorry's DISCUSS

I second Gorry's DISCUSS issues as they are sensible

### Why QUIC in Section 1

I failed to find why using QUIC is useful, especially with `EPP sessions use a
single QUIC stream for all command and response exchanges` especially when
reading section 3 `This means that a single QUIC connection may support
multiple EoQ sessions.` The introduction should probably state that there could
be several EPP sessions (for different domains ?) over a single QUIC connection.

### Section 3

`As shown in Figure 1 in Section 4,` it is painful for the reader to scroll
down. Suggest moving the figure in section 3.

s/on a well-known UDP port number assigned by IANA/on *the* well-known UDP port
number assigned by IANA/ (if there is only one)

### Section 4

Why not a "MUST" in `Absent local policy, a server SHOULD end an EoQ session
and close the QUIC stream if a well-formed command is not received within the
time limit` ?

Also note
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
(and thanks for the guidance provided for previous "SHOULD")

### Section 5

s/The 32 bits total length/The *32-bit* total length/

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate
SVG graphics. It is worth a try especially if the I-D uses the Kramdown file
format ;-)