Original text:
first Initial packet. This secret is determined by using HKDF-Extract (see Section 2.2 of <del> HKDF) with a salt of 0xafbfec289993d24c9e9786f19c6111e04390a899 and a </del>  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. output of AEAD_AES_128_GCM (AEAD) used with the following inputs: The secret key, K, is 128 bits equal to <del> 0xccce187ed09a09d05728155a6cb96be1. </del>  <del> The nonce, N, is 96 bits equal to 0xe54930f97f2136f0530a8c1c. </del>  The plaintext, P, is empty. The secret key and the nonce are values derived by calling HKDF- Expand-Label using <del> 0x8b0d37eb8535022ebc8d76a207d80df22646ec06dc809642c30a8baa2baaff4c as </del>  the secret, with labels being "quic key" and "quic iv" (protection- keys). 10. <del> This document registers the quic_transport_parameters extension found in quic_parameters in the TLS ExtensionType Values Registry TLS- REGISTRIES. </del>  <del> The Recommended column is to be marked Yes. The TLS 1.3 Column is to include CH and EE. </del> 

Reviewer comments:
Also, examples use final version numbers. IMPORTANT: the TLS extension codepoint needs to be updated, both in the text and in the examples (which will result in changes to authentication tags and the affected ciphertext).
I plugged the test vectors into the quiche test suite and it checks out URL
Hey there! We are currently implementing the Initial packet encryption process and it successfully works with the client Initial example from the appendix A.2 of the QUIC-TLS draft. However, when running tests with values for the server Initial example from the appendix A.3, tests regarding the parsing, header sampling, header protection and final encryption result all succeed, except for the header protection mask: the value we generate is: , while the draft explicitly specifies it should be something completely different: . Note that the value we generate is indeed used later on for the header protection and final encryption result, which both reveal successful. Therefore, three possibilities we thought of, in ascending order of probability: Our implementation is completely broken. The mask value provided by the current version of the specification (A.3) is correct, but all others are incorrect. Only the mask value is incorrect, while the rest is correct. We think the last option is the most probable one, as it could just mean it was forgotten to be updated in a recent draft version. If you think this is the case as well, then I would gladly open up a PR in order to close this, I just wanted to make sure beforehand. Otherwise, I would happily accept a tad of guidance towards a correct implementation. Thanks in advance, Paul.
Investigated a bit more. Looking at the result of a , we can see that: 2ebdfd53a is indeed meant to update example vectors, but does it only partially it seems: while 2ebdfd53a is for other secrets, but did it completely. So it should confirm our hypothesis.
hi NAME Our editors are taking some slight respite, we'll respond soon.
No problem NAME I was just adding some more information I forgot to mention yesterday. Thanks for the heads up :+1:
It seems to me that the header is not correct. Thoughts?
For me the header looks fine: it is consistent with the final result. What looks wrong to you NAME
I'll assign this to NAME since I think that is his code.
I can confirm this, but it won't matter as -33 will have new values entirely. The mask value should be 56fb1381e7 for the second example.
NAME would you link this issue to the PR that will update the values for -33 so it gets closed then?
New values seem to work in my testing.

Revised text:
first Initial packet. This secret is determined by using HKDF-Extract (see Section 2.2 of  <ins> HKDF) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and a </ins> 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. output of AEAD_AES_128_GCM (AEAD) used with the following inputs: The secret key, K, is 128 bits equal to  <ins> 0xbe0c690b9f66575a1d766b54e368c84e. </ins>  <ins> The nonce, N, is 96 bits equal to 0x461599d35d632bf2239825bb. </ins> The plaintext, P, is empty. The secret key and the nonce are values derived by calling HKDF- Expand-Label using  <ins> 0xd9c9943e6101fd200021506bcc02814c73030f25c79d71ce876eca876e6fca8e as </ins> the secret, with labels being "quic key" and "quic iv" (protection- keys). 10.  <ins> IANA has registered a codepoint of 57 (or 0x39) for the quic_transport_parameters extension (defined in quic_parameters) in the TLS ExtensionType Values Registry TLS-REGISTRIES. </ins>  <ins> The Recommended column for this extension is marked Yes. The TLS 1.3 Column includes CH and EE. </ins>