[TLS] "Spec Compliance" and the older TLS protocols

[Bradford Wetmore <[e-mail]>]

An interpretation question for our older RFCs, in particular TLSv1 
[RFC2246] and TLSv1.1 [RFC4346] in the context of recent developments 
[SWEET32].

In particular, likely for minimal interoperability reasons, specific 
3DES-based ciphersuites must be implemented in TLS:

TLS 1.0

    In the absence of an application profile standard specifying
    otherwise, a TLS compliant application MUST implement the cipher
    suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

TLS 1.1

    In the absence of an application profile standard specifying
    otherwise, a TLS compliant application MUST implement the cipher
    suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Ignoring the data limits approach, the degree of vendor/implementation 
response to these ciphersuites varies:

1.  default enabled/available ciphersuites remain the same,

2.  reduce the ciphersuite priority, but the ciphersuites are still 
enabled/available by default,

3.  "disable" the ciphersuites by default, but allow for reenabling 
through API or system configuration,

4.  remove the ciphersuites from the binary (e.g. via conditional 
compilation/packaging),

5.  completely remove all trace from the library's source.

So, strictly speaking from a RFC point of view (not practical or 
security POV, those are different questions), what do these "MUST 
implement" statements mean in order for an implementation to still be 
considered "spec-compliant" in the post-SWEET32 era.  1-2 above?  1-3? 
[RFC2119] isn't clear on whether 3 would be ok.

Would 4-5 be considered technically non-compliant implementations?

Thanks,

Brad

[SWEET32] https://sweet32.info/
[RFC2119] https://www.ietf.org/rfc/rfc2119.txt
[RFC2246] https://www.rfc-editor.org/rfc/rfc2246.txt
[RFC4346] https://www.rfc-editor.org/rfc/rfc4346.txt