Original text:
match a value provided in the corresponding "ECHConfig.cipher_suites" list. <del> Equal to "Expand(Extract("", config), "ech_config_digest", Nh)", where "config" is the "ECHConfig" structure and "Extract", "Expand", and "Nh" are as specified by the cipher suite KDF. (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.) </del>  The HPKE encapsulated key, used by servers to decrypt the corresponding "encrypted_ch" field. cipher_suite contains the client's chosen HpkeCipherSuite; <del> config_digest contains the digest of the corresponding ECHConfig </del>  structure; enc contains the encapsulated key as output by SetupBaseS; and but MAY be held constant for successive connections to the same server in the same session. <del> Set the "config_digest" field to a randomly-generated string of "Nh" bytes, where "Nh" is the output length of the "Extract" function of the KDF associated with the chosen cipher suite.  (The KDF API is specified in I-D.irtf-cfrg-hpke.) </del>  Set the "enc" field to a randomly-generated valid encapsulated public key output by the HPKE KEM. ClientEncryptedCH.encrypted_ch.  This matching procedure should be done using one of the following two checks: <del> Compare ClientEncryptedCH.config_digest against digests of known </del>  ECHConfig and choose the one that matches. Use trial decryption of ClientEncryptedCH.encrypted_ch with known ECHConfig and choose the one that succeeds. Some uses of ECH, such as local discovery mode, may omit the <del> ClientEncryptedCH.config_digest since it can be used as a tracking </del>  vector.  In such cases, trial decryption should be used for matching ClientEncryptedCH to known ECHConfig.  Unless specified by the application using (D)TLS or externally configured on both sides, plaintext SNI name.  This restriction allows a client to reject resumptions in auth-public-name. <del> Note that an unrecognized ClientEncryptedCH.config_digest value may be a GREASE ECH extension (see grease-extensions), so it is necessary for servers to proceed with the connection and rely on the client to </del>  abort if ECH was required.  In particular, the unrecognized value alone does not indicate a misconfigured ECH advertisement (misconfiguration).  Instead, servers can measure occurrences of the maximize the size of the anonymity set where possible.  This means client-facing servers should use the same ECHConfig for as many hosts as possible.  An attacker can distinguish two hosts that have <del> different ECHConfig values based on the ClientEncryptedCH.config_digest value.  This also means public information in a TLS handshake is also consistent across hosts.  For example, if a client-facing server services many backend origin hosts, only one of which supports some cipher suite, it may be possible to identify that host based on the contents of unencrypted handshake messages. </del>  10.2. 10.4. <del> Optional record digests may be useful in scenarios where clients and client-facing servers do not want to reveal information about the client-facing server in the "encrypted_client_hello" extension.  In such settings, clients send either an empty config_digest or a randomly generated config_digest in the ClientEncryptedCH.  (The </del>  precise implementation choice for this mechanism is out of scope for this document.)  Servers in these settings must perform trial decryption since they cannot identify the client's chosen ECH key <del> using the config_digest value.  As a result, support for optional record digests may exacerbate DoS attacks.  Specifically, an adversary may send malicious ClientHello messages, i.e., those which will not decrypt with any known ECH key, in order to force wasteful decryption.  Servers that support this feature should, for example, implement some form of rate limiting mechanism to limit the damage caused by such attacks. </del>  10.5.

Reviewer comments:
Also, rename configdigest to configid to avoid confusion with cryptographic hash digests. cc NAME NAME NAME
It's bound by the size o the HPKE KDF output size, which is unlikely to be larger than 32B. Let's make this:
We should also add a requirement for the HPKE ciphersuite. E.g., 'Nh <= 2^8`.
(Careful with fenceposts: .) If config_digest is the output of a KDF, why could you not fix the length to something that is enough to avoid collisions (16 bytes seems ample for this) and not worry about Nh at all?
I think it makes sense to let the KDF dictate the security level, i.e., the collision probability of the config_digest.
I would argue that collision probability here doesn't contribute to security. If a config is misidentified, the result will be failure, not a reduction in security. A failure either because the group doesn't match or because peers end up disagreeing on keys.
True that it's an operational consideration rather than a security one. I still think it makes sense to let the length of be dictated by the KDF, since whether truncation is an operational risk depends on the KDF.
I assume here that a KDF is capable of producing uniform random bytes of arbitrary length, meaning that truncation isn't a factor. That's what is for, right?
That assumption holds if the input has sufficient entropy. Since the public key is public, there's no entropy from the point of view of an adversary who wants to distinguish the output from random.
(To be clear, I think truncating to something reasonable, like 16 bytes, is low risk. I would be fine with doing this.)

Revised text:
match a value provided in the corresponding "ECHConfig.cipher_suites" list.  <ins> The configuration identifier, equal to "Expand(Extract("", config), "ech_config_id", Nh)", where "config" is the "ECHConfig" structure and "Extract", "Expand", and "Nh" are as specified by the cipher suite KDF.  (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.)  The length of this value SHOULD NOT be less than 16 bytes unless it is optional for an application; see optional-configs. </ins> The HPKE encapsulated key, used by servers to decrypt the corresponding "encrypted_ch" field. cipher_suite contains the client's chosen HpkeCipherSuite;  <ins> config_id contains the identifier of the corresponding ECHConfig </ins> structure; enc contains the encapsulated key as output by SetupBaseS; and but MAY be held constant for successive connections to the same server in the same session.  <ins> Set the "config_id" field to a randomly-generated string of "Nh" bytes, where "Nh" is the output length of the "Extract" function of the KDF associated with the chosen cipher suite.  (The KDF API is specified in I-D.irtf-cfrg-hpke.) </ins> Set the "enc" field to a randomly-generated valid encapsulated public key output by the HPKE KEM. ClientEncryptedCH.encrypted_ch.  This matching procedure should be done using one of the following two checks:  <ins> Compare ClientEncryptedCH.config_id against identifiers of known </ins> ECHConfig and choose the one that matches. Use trial decryption of ClientEncryptedCH.encrypted_ch with known ECHConfig and choose the one that succeeds. Some uses of ECH, such as local discovery mode, may omit the  <ins> ClientEncryptedCH.config_id since it can be used as a tracking </ins> vector.  In such cases, trial decryption should be used for matching ClientEncryptedCH to known ECHConfig.  Unless specified by the application using (D)TLS or externally configured on both sides, plaintext SNI name.  This restriction allows a client to reject resumptions in auth-public-name.  <ins> Note that an unrecognized ClientEncryptedCH.config_id value may be a GREASE ECH extension (see grease-extensions), so it is necessary for servers to proceed with the connection and rely on the client to </ins> abort if ECH was required.  In particular, the unrecognized value alone does not indicate a misconfigured ECH advertisement (misconfiguration).  Instead, servers can measure occurrences of the maximize the size of the anonymity set where possible.  This means client-facing servers should use the same ECHConfig for as many hosts as possible.  An attacker can distinguish two hosts that have  <ins> different ECHConfig values based on the ClientEncryptedCH.config_id value.  This also means public information in a TLS handshake is also consistent across hosts.  For example, if a client-facing server services many backend origin hosts, only one of which supports some cipher suite, it may be possible to identify that host based on the contents of unencrypted handshake messages. </ins> 10.2. 10.4.  <ins> Optional configuration identifiers may be useful in scenarios where clients and client-facing servers do not want to reveal information about the client-facing server in the "encrypted_client_hello" extension.  In such settings, clients send either an empty config_id or a randomly generated config_id in the ClientEncryptedCH.  (The </ins> precise implementation choice for this mechanism is out of scope for this document.)  Servers in these settings must perform trial decryption since they cannot identify the client's chosen ECH key  <ins> using the config_id value.  As a result, support for optional configuration identifiers may exacerbate DoS attacks.  Specifically, an adversary may send malicious ClientHello messages, i.e., those which will not decrypt with any known ECH key, in order to force wasteful decryption.  Servers that support this feature should, for example, implement some form of rate limiting mechanism to limit the damage caused by such attacks. </ins> 10.5.