Original text:
1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. </del>  1.2.  draft-04 Remove renegotiation.

Reviewer comments:
A straightforward cleanup of part of the backwards compatibility section. (handles an easy part of issue ) SSL 2.0 backwards compatibility was previously deprecated in TLS 1.2 (2008) and was warned to be "phased out with all due haste". RFC 6176 (2011) prohibits it entirely. It's a section of obsolete complexity still in the draft. Remove it and replace it with a simple "MUST NOT" send or accept. Edit to correct attribution of the "phased out with all due haste" language. Whilst in the TLS 1.2 (2008) spec, it was first introduced in SSL 3 (1996). It has been around for 19 years, not 5.
Dave, can you please post about this to the list?
I have to ask, why not SSL 3 as well?
This is about SSLv2 compatibility needing a different ClientHello format.
I completely agree that similar language should be added for SSL3 as well, however its prohibition RFC is not done yet. SSL2 was just an obvious start. I'll write another PR with the SSL3 prohibition draft language added in. URL
One possible idea if SSL 2.0 ClientHello compatibility is still needed is to max it at TLS 1.2.
There is discussion on list, but just let me say for the record here that I am astonished that this wasn't considered a non-controversial cleanup. The SSL2 hello has been deprecated for 20 years...
Per Brian's suggestion, this PR is now just for the changes with large agreement. Prohibiting all SSL v2 CLIENT-HELLO entirely is now moved to issue .
Per Brian's suggestion, splitting this off of PR . SSL v2 CLIENT-HELLO support requires additional implementation complexity that is an unnecessary risk to maintain support with a 20 year old deprecated negotiation format. Implementations have had notable bugs in handling this in the past. The current status quo expects them to be acceptable for negotiating TLS 1.0-1.2, even though ALL TLS clients are capable of using the SSL v3 version ClientHello if properly configured. Support for this has been optional and deprecated for many years, with the SSL 3 spec noting in 1996 that "The ability to send version 2.0 client hello messages will be phased out with all due haste. Implementers should make every effort to move forward as quickly as possible." Some implementers would be quite happy to have this prohibited entirely so that their code can finally be scrubbed clean of obsolete SSL 2 junk. Others want to perpetuate backwards compatibility support for EOL clients forever. I argue the former. A decision needs to be made on which path to chose. It will be depressing if it is to be the latter. :/
It is now no longer possible to use SSLv2 hellos with TLS 1.3 (because some extensions are mandatory) so we shouldn't need anythign here.

Revised text:
1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",  <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. </ins> 1.2. <ins> draft-05 Prohibit SSL negotiation for backwards compatibility. </ins> draft-04 Remove renegotiation.