Original text:
Authentication: The server side of the channel is always authenticated; the client side is optionally authenticated. Authentication can happen via asymmetric cryptography (e.g., RSA <del> RSA, the Elliptic Curve Digital Signature Algorithm (ECDSA) ECDSA, </del>  or the Edwards-Curve Digital Signature Algorithm (EdDSA) RFC8032) or a symmetric pre-shared key (PSK). "signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2. <del> Indicates a signature algorithm using ECDSA ECDSA, the corresponding curve as defined in ANSI X9.62 ECDSA and FIPS 186-4 DSS, and the corresponding hash algorithm as defined in SHS.  The signature is represented as a DER-encoded X690 ECDSA-Sig-Value structure as defined in RFC4492. </del>  Indicates a signature algorithm using RSASSA-PSS with a mask generation function of MGF1, as defined in RFC8017.  The digest %%% Supported Groups Extension Indicates support for the corresponding named curve, defined in <del> either FIPS 186-4 DSS or in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for Private Use RFC8126. </del>  Indicates support for the corresponding finite field group, defined in RFC7919.  Values 0x01FC through 0x01FF are reserved for For the curves secp256r1, secp384r1, and secp521r1, peers MUST validate each other's public value Q by ensuring that the point is a valid point on the elliptic curve.  The appropriate validation <del> procedures are defined in Section 4.3.7 of ECDSA and alternatively in </del>  Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three steps: (1) verify that Q is not the point at infinity (O), (2) verify that for Q = (x, y) both integers x and y are in the correct

Reviewer comments:
FIPS 186-4 is obsolete Curve definitions have moved to the new NIST SP 800-186 ANSI X9.62 is behind a paywall and should be avoided if possible. References behind paywall can not be accessed by most readers. This makes it harder to implement and to evaluate the security of the protocol. FIPS 186-5 removed the dependency on ANSI X9.62 and defines ECDSA itself. Point validation is defined in the new NIST SP 800-186.

Revised text:
Authentication: The server side of the channel is always authenticated; the client side is optionally authenticated. Authentication can happen via asymmetric cryptography (e.g., RSA  <ins> RSA, the Elliptic Curve Digital Signature Algorithm (ECDSA) DSS, </ins> or the Edwards-Curve Digital Signature Algorithm (EdDSA) RFC8032) or a symmetric pre-shared key (PSK). "signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2.  <ins> Indicates a signature algorithm using ECDSA DSS, the corresponding curve as defined in NIST SP 800-186 ECDP, and the corresponding hash algorithm as defined in SHS.  The signature is represented as a DER-encoded X690 ECDSA-Sig-Value structure as defined in RFC4492. </ins> Indicates a signature algorithm using RSASSA-PSS with a mask generation function of MGF1, as defined in RFC8017.  The digest %%% Supported Groups Extension Indicates support for the corresponding named curve, defined in  <ins> either NIST SP 800-186 ECDP or in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for Private Use RFC8126. </ins> Indicates support for the corresponding finite field group, defined in RFC7919.  Values 0x01FC through 0x01FF are reserved for For the curves secp256r1, secp384r1, and secp521r1, peers MUST validate each other's public value Q by ensuring that the point is a valid point on the elliptic curve.  The appropriate validation  <ins> procedures are defined in Appendix D.1 of ECDP and alternatively in </ins> Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three steps: (1) verify that Q is not the point at infinity (O), (2) verify that for Q = (x, y) both integers x and y are in the correct