Change:
This was, I think clear, but the use of HKDF-Expand-Label and the encoding of labels into octets could be even more explicit.
Section 5.2: The secret used by clients to construct Initial packets uses the PRK and the label "client in" as input to the HKDF-Expand-Label function to produce a 32 byte secret; packets constructed by the server use the same process with the label "server in". The hash function for HKDF when deriving initial secrets and keys is SHA-256 [SHA]. Looking at RFC 5689 the HKDF-Expand function defines what is referenced as label as "info" input. It is a string. It is unclear that this is an ASCII string, but based on what is written it looks like something where each character is an octet is assumed, thus no UTF-16 or UTF-32 strings would work as intended. If I am correct I think the draft can be improved by being explicit like in TLS that the label used as input into the functions as ASCII. So adding something like this sentence from RFC8446 is likely appropriate: The labels specified in this document are all ASCII strings and do not include a trailing NUL byte.
Actually I think I understand what the issue is: Lets look at these three paragraphs in Section 5.2: This secret is determined by using HKDF-Extract (see Section 2.2 of [HKDF]) with a salt of 0xafbfec289993d24c9e9786f19c6111e04390a899 and a IKM of the Destination Connection ID field. This produces an intermediate pseudorandom key (PRK) that is used to derive two separate secrets for sending and receiving. The secret used by clients to construct Initial packets uses the PRK and the label "client in" as input to the HKDF-Expand-Label function to produce a 32 byte secret; packets constructed by the server use the same process with the label "server in". The hash function for HKDF when deriving initial secrets and keys is SHA-256 [SHA]. The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for Initial packets even where the TLS versions offered do not include TLS 1.3. I got the impression that the HKDF-Expand function was the one from RFC5689 and not the one from TLS1.3. So I think what is needed to clarify this is that the second paragraph needs to explicitly provide the HKDF-Expand-label function with section and document reference. I still think it should be made clear that the labels are ASCII, but that is clear in TLS 1.3 compared to RFC5689.
Based on , labeling this as "editorial"
Changes looks good, resolve the issue.
nits

Discussion:
The keys used for packet protection are computed from the TLS secrets using the KDF provided by TLS.  In TLS 1.3, the HKDF-Expand-Label function described in Section 7.1 of TLS13 is used, using the hash <del> function from the negotiated cipher suite.  Other versions of TLS MUST provide a similar function in order to be used with QUIC. </del> <ins> function from the negotiated cipher suite.  Note that labels, which are described using strings, are encoded as bytes using ASCII ASCII without quotes or any trailing NUL byte.  Other versions of TLS MUST provide a similar function in order to be used with QUIC. </ins> The current encryption level secret and the label "quic key" are input to the KDF to produce the AEAD key; the label "quic iv" is used

The secret used by clients to construct Initial packets uses the PRK and the label "client in" as input to the HKDF-Expand-Label function <del> to produce a 32 byte secret; packets constructed by the server use the same process with the label "server in".  The hash function for HKDF when deriving initial secrets and keys is SHA-256 SHA. </del> <ins> from TLS TLS13 to produce a 32-byte secret.  Packets constructed by the server use the same process with the label "server in".  The hash function for HKDF when deriving initial secrets and keys is SHA-256 SHA. </ins> This process in pseudocode is: