Change:
I took this bit out of the 1st paragraph: -If any of these parameters has no overlap between the -client and server parameters, then the handshake -will fail. and moved it to the last para in the section because it doesn't say what alert value is to be returned, there's not something similar in the following paragraph that describes the PSK failure case, and finally the full failure text is included in the final paragraph. Basically, I just move the failure case to the final paragraph. An alternate would be to copy the failure to the PSK paragraph and include the which alert to return in the non-PSK para.

Discussion:
4.1.1. TLS cryptographic negotiation proceeds by the client offering the <del> following four sets of options in its ClientHello. </del> <ins> following four sets of options in its ClientHello: </ins> A list of cipher suites which indicates the AEAD cipher/HKDF hash <del> pairs which the client supports </del> <ins> pairs which the client supports. </ins> A "supported_group" (negotiated-groups) extension which indicates the (EC)DHE groups which the client supports and a "key_share" (key-share) extension which contains (EC)DHE shares for some or <del> all of these groups </del> <ins> all of these groups. </ins> A "signature_algorithms" (signature-algorithms) extension which indicates the signature algorithms which the client can accept.

options are entirely orthogonal: the server independently selects a cipher suite, an (EC)DHE group and key share for key establishment, and a signature algorithm/certificate pair to authenticate itself to <del> the client.  If any of these parameters has no overlap between the client and server parameters, then the handshake will fail.  If there is overlap in the "supported_group" extension but the client did not offer a compatible "key_share" extension, then the server will respond with a HelloRetryRequest (hello-retry-request) message. </del> <ins> the client.  If there is overlap in the "supported_group" extension but the client did not offer a compatible "key_share" extension, then the server will respond with a HelloRetryRequest (hello-retry- request) message. </ins> If the server selects a PSK, then the PSK will indicate which key establishment modes it can be used with (PSK alone or with (EC)DHE)

in either of these parameters need not be fatal. The server indicates its selected parameters in the ServerHello as <del> follows: If PSK is being used then the server will send a "pre_shared_key" extension indicating the selected key.  If PSK is not being used, then (EC)DHE and certificate-based authentication are always used.  When (EC)DHE is in use, the server will also provide a "key_share" extension.  When authenticating via a certificate, the server will send an empty "signature_algorithnms" extension in the ServerHello and will subsequently send Certificate (certificate) and CertificateVerify (certificate-verify) messages. If the server is unable to negotiate a supported set of parameters, </del> <ins> follows: If PSK is being used then the server will send a "pre_shared_key" extension indicating the selected key. If PSK is not being used, then (EC)DHE and certificate-based authentication are always used. When (EC)DHE is in use, the server will also provide a "key_share" extension. When authenticating via a certificate, the server will send an empty "signature_algorithnms" extension in the ServerHello and will subsequently send Certificate (certificate) and CertificateVerify (certificate-verify) messages. If the server is unable to negotiate a supported set of parameters (i.e., there is no overlap between the client and server parameters), </ins> it MUST return a "handshake_failure" alert and close the connection. 4.1.2.