Original text:
If the server supports wildcard names, it SHOULD set this value to 260. <del> The moment when the keys become valid for use.  The value is represented as seconds from 00:00:00 UTC on Jan 1 1970, not including leap seconds. The moment when the keys become invalid.  Uses the same unit as not_before. </del> A list of extensions that the client can take into consideration when generating a Client Hello message.  The format is defined in RFC8446; Section 4.2.  The purpose of the field is to provide room including those caused by intermediaries such as a DNS proxy running on a home router. <del> "not_before" and "not_after" fields represent the validity period of the published ESNI keys.  Clients MUST NOT use ESNI keys that was covered by an invalid checksum or beyond the published period.  If none of the ESNI keys values are acceptable, the client SHOULD behave as if no ESNI records were found. Servers SHOULD set the Resource Record TTL small enough so that the record gets discarded by the cache before the ESNI keys reach the end of their validity period.  Note that servers MAY need to retain the decryption key for some time after "not_after", and will need to consider clock skew, internal caches and the like, when selecting the "not_before" and "not_after" values. Client MAY cache the ESNIRecord values for a particular domain based on the TTL of the Resource Record, but SHOULD NOT cache them based on the not_after value of the ESNIKeys structure, to allow servers to rotate the keys often and improve forward secrecy. </del> Note that the length of the ESNIRecord structure MUST NOT exceed 2^16 - 1, as the RDLENGTH is only 16 bits RFC1035.

Reviewer comments:
We now have a proper retry mechanism, so we don't need to prevent clients to connect using expired keys anymore.
NAME notes that the notbefore and notafter fields are there and described, but not really part of the operational notes. Having something there that talks about these, particularly as it relates to clock skew, would be valuable.
(My ~monthly login into URL - this'd be better on the TLS WG list, and I will send mail on this sometime but anyway...) The not-before and not-after fields are a mistake. Same as turned out true for x.509. I was just doing testing where FF nightly barfed on ESNIKeys I'd published for only that non-reason. (There is no overall security win in so-doing, in general.) Creating a tangle between the cadence at which one updates DNS, the ESNIKeys-internal "lifetime" of a key, the DNS TTL and server-state is basically just pointless nonsense. Let's delete those fields from ESNIKeys before we're done and just rely on DNS for what it already does.
Now that has been merged, I agree that there is less need for notbefore and notafter fields. Previously, a client using an expired key led to connection failure, and therefore having these fields were necessary.
Fixed by removing these fields with .
Thank you for the PR. LGTM

Revised text:
If the server supports wildcard names, it SHOULD set this value to 260.  A list of extensions that the client can take into consideration when generating a Client Hello message.  The format is defined in RFC8446; Section 4.2.  The purpose of the field is to provide room including those caused by intermediaries such as a DNS proxy running on a home router.  Note that the length of the ESNIRecord structure MUST NOT exceed 2^16 - 1, as the RDLENGTH is only 16 bits RFC1035.