Change:
"elliptic_curves" and only contained elliptic curve groups.  See RFC4492 and I-D.ietf-tls-negotiated-ff-dhe. <ins> All clients MUST send a valid "supported_groups" extension containing at least one group for each ephemeral key exchange algorithm (currently DHE and ECDHE) for which it offers a cipher suite. Servers MUST NOT negotiate use of a DHE or ECDHE cipher suites unless the client supplies a supported NamedGroup.  If the extension is not provided and no alternative cipher suite is available, the server MUST close the connection with a fatal "missing_extension" alert. (see mti-extensions) If the extension is provided, but no compatible group is offered, the server MUST NOT negotiate a cipher suite of the relevant type.  For instance, if a client supplies only ECDHE groups, the server MUST NOT negotiate finite field Diffie-Hellman.  If no acceptable group can be selected across all cipher suites, then the server MUST generate a fatal "handshake_failure" alert. Servers MUST NOT send this extension.  TLS servers MUST support receiving this extension.  Clients receiving this extension MUST respond with an "unsupported_extension" alert and close the connection. </ins> The "extension_data" field of this extension contains a "NamedGroupList" value:

Discussion:
Modified extension requirements based on recent list discussion. It's a little verbose with repeated boilerplate, but it's clear no matter which section you read now. I've also moved the relevant requirements up top to a consistent place for each extension's section. The level of strictness here is now: If attempting to negotiate and the mandatory extension isn't available: MUST error If just detecting an invalid combination, but not actively negotiating: MAY error SNI is clearly listed as MUST support, servers MAY require, and SHOULD error if required The "unsupportedextension" alert is reworded more generally and put in as the consequence for violating the pre-existing "MUST NOT" send the client-only extensions from a server requirements. Also added some more, namely the fact that "clientkey_share" is clearly an error to be sent from a server.
NAME & NAME Please take a look when you get a chance. Are we all on the same page with this language? Anything that needs tweaking to focus on the above better? Edited to add: Also, do I need to cut out SNI again, or is this wording ok? It's not requiring it to be sent, just noting it must be supported, which was agreed to on list a while ago, and noting the existing case that servers MAY require it with a way to indicate it using the new error alert.
NAME New commit pushed here with changes for your comments: "invalid" -> "prohibited" Text is now: "Servers MUST NOT negotiate use of cipher suites unless the client supplies a supported . If the extension is not provided and no alternative cipher suite is available, the server MUST close the connection with a fatal "missing_extension" alert." So, trying to find a viable cipher suite is preferred and the error is only required when there's nothing else to do. Edited to note: The latter doesn't contradict the mandatory error on negotiation without the needed extension, as the server simply has the (unlikely) chance of negotiating something completely different instead. The MAY error is still included later in the changeset, as discussed, so clients are still expected to always do this correctly or risk the server throwing an error.
NAME Ok, repushed with one-word change to clarify to "at least one group for each ephemeral key exchange algorithm". This excludes PSK, but is still fine for (EC)DHE when used with it. Seems like the simplest fix.