Change:
The goal of the reinit proposal is to trigger a tear down / restart of a group with the same members but different parameters such as a version upgrade, or a cipher suite change. Changing version - version is a field within key package, and this locks a key package to a specific version, even if capabilities allow for multiple versions. Should that field be removed, and instead you just look at capabilities? It seems that this would change with since leaf nodes will not be pinned to a specific version, just a cipher suite. After 575 gets merged one could upgrade versions using a new tree that copies the current non-empty leaves so long as each leaf has the upgraded version in their capabilities set. That specific tree building process is not mentioned, it is just sort of assumed in context. Changing cipher suite - In the case you want to change cipher suite, complexity somewhat increases. You will need to create a new tree by grabbing new key packages for each participant, and because the cipher suite has changed, all of the credentials have also changed. It is mentioned that "A group may be reinitialized by creating a new group with the same membership and different parameters", but this does not have a statement that has a SHOULD or MUST associated with it. For example, in my 5000 member group 1 member does not support the cipher suite that we are migrating away from. As the committer, I'm assuming that I should keep everyone in the group as best effort, but have the option to filter out problematic members that are blocking a migration due to them being offline for long periods of time or having outdated software. Due to the credential change, enforcing a MUST might be difficult since equality between two x509 credentials is not straight forward for example. To summarize, I propose some changes Remove version from key package, and rely on capabilities instead, this may now be irrelevant due to , but the version and capabilities.versions values seem duplicative Add some language in reinitialization that clarifies the flow for upgrading just version vs changing cipher suite, where changing cipher suite explicitly requires you acquire new key packages for each member. Clarify that a person issuing the welcome based on a reinit proposal SHOULD include all existing members
IMO those fields have quite separate purposes. Keep in mind that a different version could have a different KeyPackage format. So says "this KeyPackage is formatted according to this version", while the capabilities says what other versions I support. With that in mind, you need to grab new KeyPackages for everyone regardless of whether you're changing version, ciphersuite, or both. If this isn't clear, we should certainly clarify it. If you're worried about people not supporting the new stuff, you could maintain the hard semantic just by Removing those participants that don't support the new stuff before you ReInit.
Fair enough that seems reasonableI don't think it's necessarily clear right now, it's more of an assumption based on an understanding of the protocol overall. I'll try to come up with something there to give more of a step by step explanation of the flow.If this is a hard requirement should the doc say MUST here? If so, I'm trying to think through what equality means in terms of membership when in the event the cipher suite changes, all the credentials will also change.
On (3) -- I would be OK with saying that the new members MUST be the same as the old members. The notion of "same" is a little squishy, given ambiguities around identifiers, but it seems like it will probably be clear in practice. W.r.t. removing people to make an upgrade possible, when the application decides to upgrade and how the application it meets the same-member criterion is up to the application.
Discussion on virtual interim: Maybe put "remove before upgrade" in implementation considerations document.
NAME I meant to make this call to discuss, seem to not have the invite anymore, can you forward it to me? In terms of where this ticket is at, I was mostly raising the concerns to clarify for myself that what I think is the process is actually the process. I am willing to just close this one out

Discussion:
Abstract <del> -- middle </del> <ins> Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, not any servers involved in delivering messages.  Establishing keys to provide such protections is challenging for group chat settings, in which more than two participants need to agree on a key.  In this document, we specify a group key establishment protocol that provides efficient group key establishment with forward secrecy and post-compromise security. 1. [[ TODO - Group keying is necessary, but hard.  State of the art is sender keys, which have bad FS / PCS and bad rekey efficiency ]] 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. 3. 3.1. 3.2. 3.3. 3.4. 4. [[ Session comprised of (1) ART (2) pre-stage key (3) message key chains ]] [[ Each node caches... ]] 5. 5.1. 5.2. 5.2.1. 5.2.2. 5.2.3. 5.2.4. 6. [[ What trust is placed in the server? ]] 7. </ins>