Change:
12. <ins> The base MLS protocol can be extended in a few ways.  New ciphersuites can be added to enable the use of new cryptographic algorithms.  New types of proposals can be used to perform new actions within an epoch.  Extension fields can be used to add additional information to the protocol.  In this section, we discuss some constraints on these extensibility mechanisms that are necessary to ensure broad interoperability. 12.1. As discussed in ciphersuites, MLS allows the participants in a group to negotiate the cryptographic algorithms used within the group. This extensibility is important for maintaining the security of the protocol over time RFC7696.  It also creates a risk of interoperability failure due to clients not supporting a common ciphersuite. The ciphersuite registry defined in mls-ciphersuites attempts to strike a balance on this point.  On the one hand, the base policy for the registry is Specification Required, a fairly low bar designed to avoid the need for standards work in cases where different ciphers are needed for niche applications.  There is a higher bar (Standards Action) for ciphers to set the Recommended field in the registry. This higher bar is there in part to ensure that the interoperability implications of new ciphersuites are considered. MLS ciphersuites are defined independent of MLS versions, so that in principle the same ciphersuite can be used across versions. Standards work defining new versions of MLS should consider whether it is desirable for the new version to be compatible with existing ciphersuites, or whether the new version should rule out some ciphersuites.  For example, a new version could follow the example of HTTP/2, which restricted the set of allowed TLS ciphers (see Section 9.2.2 of RFC7540. 12.2. Commit messages do not have an extension field because the set of protocols is extensible.  As discussed in commit, Proposals with a non-default proposal type MUST NOT be included in a commit unless the proposal type is supported by all the members of the group that will process the Commit. 12.3. </ins> This protocol includes a mechanism for negotiating extension parameters similar to the one in TLS RFC8446.  In TLS, extension negotiation is one-to-one: The client offers extensions in its

Discussion:
proposes to remove redundancy between version fields and ciphersuites by removing the version fields. This PR removes the version from the ciphersuite instead.
NAME suggests adding some advisory text in the extensibility section to the effect that future versions of the protocol should consider whether they want to keep all defined ciphersuites.
NAME here is some text we put in RFC 8447 (IANA registries for TLS) that was also included in the IANA registry to warn about cipher suites getting weaker over time. This could be modified to mention culling at different version. WARNING: : Cryptographic algorithms and parameters will be broken or weakened over time. Blindly implementing cipher suites listed here is not advised. Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security.
Affiliation -> Meta Platforms Address -> EMAIL
In , the field of is removed. I'm guessing the reason was that is was redundant with the ciphersuite, since the MLS version is at the time included in the ciphersuite. However, in , MLS versions were removed from ciphersuites, making the protocol version not redundant anymore with the ciphersuite. We should probably put the MLS version back there?
I just discovered that this is then fixed by adding the MLS version to in , closing.