Original text:
ANSI X9.62 ANSI.X9-62.2005 and FIPS 186-4 FIPS.186-4.  The rest of this document refers to these three curves as the "NIST curves" because they were originally standardized by the National Institute <del> of Standards and Technology.  The curves ecdh_x25519 and ecdh_x448 are defined in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for private use. </del>  The predecessor of this document also supported explicitly defined prime and char2 curves, but these are deprecated by this mechanism.) ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte string ECPoint.point, which may represent an elliptic curve point <del> in uncompressed or compressed format.  Curves eddsa_ed25519 and eddsa_ed448 MUST NOT be used here.  Here, the format MUST conform to what the server has requested through a Supported Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not used. </del>  Actions of the sender: domain parameters recommended in ANSI X9.62, FIPS 186-4, and SEC 2 SECG-SEC2 or in RFC8032. <del> EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the eddsa_ed25519 curve, and Ed448 and Ed448ph keys MUST use the eddsa_ed448 curve.  Curves ecdh_x25519, ecdh_x448, eddsa_ed25519 and eddsa_ed448 MUST NOT be used for ECDSA. </del>  5.10. future TLS versions or new TLS extensions introduced in the future may vary this computation.) <del> An ECDHE key exchange using X25519 (curve ecdh_x25519) goes as follows: Each party picks a secret key d uniformly at random and computes the corresponding public key x = X25519(d, G).  Parties exchange their public keys, and compute a shared secret as x_S = X25519(d, x_peer).  If either party obtains all-zeroes x_S, it MUST abort the handshake (as required by definition of X25519 and X448). ECDHE for X448 works similarily, replacing X25519 with X448, and ecdh_x25519 with ecdh_x448.  The derived shared secret is used directly as the premaster secret, which is always exactly 32 bytes when ECDHE with X25519 is used and 56 bytes when ECDHE with X448 is used. </del>  All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result IANA, please update these two registries to refer to this document. <del> IANA has already assigned the value 29 to ecdh_x25519, and the value 30 to ecdh_x448. </del>  IANA is requested to assign two values from the TLS SignatureAlgorithm Registry with names ed25519(TBD3) and ed448(TBD4)

Reviewer comments:
ecdhx25519 and ecdhx448 no longer have an ecdh_ prefix (.Remove some remnants of EdDSA curves as NamedCurves.TLS 1.3 only uses the PureEdDSA algorithms. If we were to use Ed25519ph, we would want separate SignatureAlgorithm values so the receivers can indicate support.
(NAME suggested I file this here.) In TLS 1.3, we dropped the "ecdh" prefix on ecdhx25519 and ecdh_x448 when we split signatures from NamedCurve/Group. The documents should probably match in naming one way or another. I think plain x25519 and x448 is tidier. X25519 already denotes the ECDH function, as opposed to curve25519 which is the curve.
Looks fine to me

Revised text:
ANSI X9.62 ANSI.X9-62.2005 and FIPS 186-4 FIPS.186-4.  The rest of this document refers to these three curves as the "NIST curves" because they were originally standardized by the National Institute  <ins> of Standards and Technology.  The curves x25519 and x448 are defined in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for private use. </ins> The predecessor of this document also supported explicitly defined prime and char2 curves, but these are deprecated by this mechanism.) ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte string ECPoint.point, which may represent an elliptic curve point  <ins> in uncompressed or compressed format.  Here, the format MUST conform to what the server has requested through a Supported Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not used. </ins> Actions of the sender: domain parameters recommended in ANSI X9.62, FIPS 186-4, and SEC 2 SECG-SEC2 or in RFC8032.  <ins> EdDSA keys using the Ed25519 algorithm MUST use the ed25519 signature algorithm, and Ed448 keys MUST use the ed448 signature algorithm. This document does not define use of Ed25519ph and Ed448ph keys with TLS.  Ed25519, Ed25519ph, Ed448, and Ed448ph keys MUST NOT be used with ECDSA. </ins> 5.10. future TLS versions or new TLS extensions introduced in the future may vary this computation.)  <ins> An ECDHE key exchange using X25519 (curve x25519) goes as follows: Each party picks a secret key d uniformly at random and computes the corresponding public key x = X25519(d, G).  Parties exchange their public keys, and compute a shared secret as x_S = X25519(d, x_peer). If either party obtains all-zeroes x_S, it MUST abort the handshake (as required by definition of X25519 and X448).  ECDHE for X448 works similarily, replacing X25519 with X448, and x25519 with x448.  The derived shared secret is used directly as the premaster secret, which is always exactly 32 bytes when ECDHE with X25519 is used and 56 bytes when ECDHE with X448 is used. </ins> All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result IANA, please update these two registries to refer to this document.  <ins> IANA is requested to assigned the value 29 to x25519, and the value 30 to x448 in the TLS Supported Groups Registry.  This replaces the temporary registrations ecdh_x25519(29) and ecdh_x448(30). </ins> IANA is requested to assign two values from the TLS SignatureAlgorithm Registry with names ed25519(TBD3) and ed448(TBD4)