Original text:
a version they do not understand.  [[NOTE: This means that the RFC will presumably have a nonzero value.]] <del> The first four (4) octets of the SHA-256 message digest RFC6234 of the ESNIKeys structure.  For the purpose of computing the checksum, the value of the "checksum" field MUST be set to zero. </del> The non-empty name of the entity trusted to update these encryption keys.  This is used to repair misconfigurations, as described in handle-server-response. query domain name's canonicalized form.  That is, if a client queries example.com, the ESNI Resource Record might be: <del> The "checksum" field provides protection against transmission errors, including those caused by intermediaries such as a DNS proxy running on a home router. </del>  Note that the length of the ESNIRecord structure MUST NOT exceed 2^16 - 1, as the RDLENGTH is only 16 bits RFC1035. shared used to derive the ESNI key. A cryptographic hash of the ESNIKeys structure from which the ESNI <del> key was obtained, i.e., from the first byte of "checksum" to the </del>  end of the structure.  This hash is computed using the hash function associated with "suite".

Reviewer comments:
The checksum seems to add little value with the retry mechanism and record_digest. I think we should remove it. See for some context.
The I-D says: "recorddigest : A cryptographic hash of the ESNIKeys structure from which the ESNI key was obtained, i.e., from the first byte of "checksum" to the end of the structure. This hash is computed using the hash function associated with suite." From looking at the NSS code it appears that the recorddigest input is actually the entire ESNIKeys (after base64 decode) including the version and checksum. Is that correct? IOW, does the following also produce the right value (for CF and sha256)? `
proposes removing the checksum, which should clear this up.
Closing since landed. NAME please re-open if this is still an issue!
The hash used in the extension should use the same hash inputs as the checksum. The difference here just makes using this harder.
I support the change, if that makes people feel more comfortable about having the checksum field in ESNIKeys.
I'm not opposed, but it doesn't help as much as you might think, because you need to compute the label with the cipher hash and not (necessarily) with SHA-256.
So, if you take my suggestion in (which I know NAME doesn't like, but we simply disagree about that), then you can identify the ESNI using a truncated hash that is calculated using the cipher hash because it only appears in the context of a handshake. But that just suggests that this is either not-helpful because we chose not to do anything in , or it is not necessary because we did. I'm OK closing this on that basis.
Checksum is now gone. Closing this issue. NAME thanks for filing it!
I agree that we can now and should make this simplification. The PR looks good to me.

Revised text:
a version they do not understand.  [[NOTE: This means that the RFC will presumably have a nonzero value.]]  The non-empty name of the entity trusted to update these encryption keys.  This is used to repair misconfigurations, as described in handle-server-response. query domain name's canonicalized form.  That is, if a client queries example.com, the ESNI Resource Record might be:  <ins> In the event that ESNIKeys is corrupt in transit or otherwise invalid, servers will initiate the retry mechanism described in server-behavior and deliver valid ESNIKeys to clients. </ins> Note that the length of the ESNIRecord structure MUST NOT exceed 2^16 - 1, as the RDLENGTH is only 16 bits RFC1035. shared used to derive the ESNI key. A cryptographic hash of the ESNIKeys structure from which the ESNI  <ins> key was obtained, i.e., from the first byte of "version" to the </ins> end of the structure.  This hash is computed using the hash function associated with "suite".