Original text:
format-key-config shows a single . <del> The definitions for the identifiers used in HPKE and the semantics of the algorithms they identify can be found in HPKE.  The "Npk" parameter is determined by the choice of HPKE KEM, which can also be found in HPKE. </del>  3.2. This plaintext Request is encapsulated into a message in ""message/ ohttp-req"" form by generating an .  An comprises a key identifier; HPKE parameters for the chosen KEM, KDF, and AEAD; the encapsulated <del> KEM shared secret (or "enc"); and the HPKE-protected binary HTTP </del>  request message. An is shown in fig-enc-request. request describes the process for constructing and processing an . <del> The Nenc parameter corresponding to the KEM used in HPKE can be found in HPKE or the HPKE KEM IANA registry [1].  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. </del>  4.2. An is shown in fig-enc-response. response describes the process for constructing and processing an . <del> The Nn and Nk values correspond to parameters of the AEAD used in HPKE, which is defined in HPKE or the HPKE AEAD IANA registry [2]. Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </del>  4.3. 9. Please update the "Media Types" registry at <del> https://iana.org/assignments/media-types [3] for the media types </del>  "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). Please update the "HTTP Problem Types" registry at <del> https://iana.org/assignments/http-problem-types [4] for the types </del>  "date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key). 9.1. 10.1.  URIs <del> [1] https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids </del>  <del> [2] https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids </del>  <del> [3] https://iana.org/assignments/media-types [4] https://iana.org/assignments/http-problem-types </del>  Index

Reviewer comments:
We previously only had figures, which are sort of illustrative only, they don't really work as normative specification. The content of these really needs to have words that describe what was intended. The definition for the request was already sort-of there, so what I've added is a tiny bit repetitive, but I think that it's OK in this case to have the descriptions at different levels of specificity. The big error here was that the length field in the key configuration was impossible to decipher. We never said whether it was length in bytes (what has been implemented) or length in number of items. The bounds on the field length were not helpful here as they were not correct in any way. I've corrected this value, but would appreciate a sanity check. No one identified this as a problem in the reviews. I guess that means that the QUIC format is clear and understandable. Maybe I should have made it less so. The TLS format is consistently misunderstood, which I used to think was a disadvantage...

Revised text:
format-key-config shows a single .  <ins> That is, a consists of the following fields: </ins> 3.2. This plaintext Request is encapsulated into a message in ""message/ ohttp-req"" form by generating an .  An comprises a key identifier; HPKE parameters for the chosen KEM, KDF, and AEAD; the encapsulated  <ins> KEM shared secret (or "enc"); and an HPKE-protected binary HTTP </ins> request message. An is shown in fig-enc-request. request describes the process for constructing and processing an .  <ins> That is, an comprises a Key Identifier, HPKE KEM ID, HPKE KDF ID, HPKE AEAD ID, Encapsulated KEM Shared Secret, and HPKE-Protected Request.  The Key Identifier, HPKE KEM ID, HPKE KDF ID, and HPKE AEAD ID fields are defined in key-config.  The Encapsulated KEM Shared Secret is the output of the "Encap()" function for the KEM, which is "Nenc" bytes in length, as defined in HPKE. </ins> 4.2. An is shown in fig-enc-response. response describes the process for constructing and processing an .  <ins> That is, an contains a Nonce and an AEAD-Protected Response.  The Nonce field is either "Nn" or "Nk" bytes long, whichever is larger. The "Nn" and "Nk" values correspond to parameters of the AEAD used in HPKE, which is defined in HPKE or the HPKE AEAD IANA registry [1]. "Nn" and "Nk" refer to the size of the AEAD nonce and key respectively, in bytes. </ins> 4.3. 9. Please update the "Media Types" registry at  <ins> https://iana.org/assignments/media-types [2] for the media types </ins> "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). Please update the "HTTP Problem Types" registry at  <ins> https://iana.org/assignments/http-problem-types [3] for the types </ins> "date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key). 9.1. 10.1.  URIs  <ins> [1] https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids </ins>  <ins> [2] https://iana.org/assignments/media-types </ins>  <ins> [3] https://iana.org/assignments/http-problem-types </ins> Index