Change:
the group. The Commit MUST NOT combine proposals sent within different epochs. <del> In the event that a valid proposal is omitted from the next Commit, the sender of the proposal SHOULD retransmit it in the new epoch. </del> <ins> Due to the asynchronous nature of proposals, receivers of a Commit SHOULD NOT enforce that all valid proposals sent within the current epoch are referenced by the next Commit.  In the event that a valid proposal is omitted from the next Commit, and that proposal is still valid in the current epoch, the sender of the proposal MAY retransmit it. </ins> A member of the group MAY send a Commit that references no proposals at all, which would thus have an empty "proposals" vector.  Such a

Discussion:
Addresses the comments in ( ) Since a member performing a commit including all valid proposals within an epoch is best effort, it makes sense to downgrade the requirement from MUST to SHOULD. IMO, MUST should be reserved for instances where the receiver would throw an error in the condition the sender did not 100% comply with the rule. Since in this case it is not a hard error under certain conditions, such as the member performing the commit having not received a proposal in transit while generating the commit, SHOULD is a better choice.
I'm not sure this PR addresses the issues raised in , especially regarding the redundancy of proposals. I would suggest the following: The sender of a commit SHOULD use all valid non-redundant proposals it has received In the event that a valid non-redundant proposal is omitted from the next Commit, the sender of the proposal SHOULD retransmit it in the new epoch
Re: non-redundant: I'm not sure we need to say "valid non-redundant". We can just include non-redundancy in the definition of "valid". Re: retransmit: I would frame this as "If a group member sent a proposal within an epoch that was not included in a Commit that initiates the next epoch, then the proposer MAY retransmit the proposal in the new epoch."
I believe the existing language in the "if there are multiple proposals ..." paragraph covers the non-redundant aspect of the requirements. How about this for retransmit? I can push a new commit if we think this helps "The Commit MUST NOT combine proposals sent within different epochs. In the event that a valid proposal is omitted from the next Commit, and that proposal is still valid in the current epoch, the sender of the proposal MAY retransmit it."
I think that works.
Pushed a commit to add the copy in my comment
Discussion on working call: Agreement to soften receiver requirement, keep MUST on sender NAME to update, then we can merge
Just posted new wording, let me know what you think
Looks good to me, thanks NAME
There are several rules in terms of selecting proposals and issuing commits against them. I have distilled the existing wording in the document into the following rules If there are multiple updates for the same leaf, cherry pick one.

If there is a remove and an update/add for the same key package, always choose remove If there are multiple group context extension updates, cherry pick one The sender of a commit MUST use all valid proposals it has received In the event that a valid proposal is omitted from the next Commit, the sender of the proposal SHOULD retransmit it in the new epoch It seems that rule 4 and rule 5 conflict with each other in that one is suggesting that all proposals must be consumed or there should be a hard error, and the other assumes it is possible for a commit to purposefully leave out a proposal and it can optionally be retransmitted. I have been trying to write code that reasonably handles the cherry picking logic around multiple proposals referencing the same key package or multiple changes to group context while also enforcing the "must use all valid proposals received" rule, and it does introduce some complexity that maybe would be avoided by just eliminating that rule?
Good point. One situation where rule 5 would make sense is if we prohibit proposals by reference in external commits to solve the problems outlined in . Rule 5 would otherwise make sense in situations, where there's no agreement on whether a proposal is valid. One case where this is necessarily the case is the following: A remove proposal was sent, but the client that is to be removed is the committer in this epoch. The client can't commit their own removal, but the proposal is still technically valid from the proposer's point of view. There might be other situations, for example, where the application imposes some sort of policy that different clients interpret differently. This should be the application's problem, though.
I think what I'm trying to boil this down to is, should my implementation throw an error if all proposals are not consumed by the process of applying the commit I just received? I'm still thinking enforcing that would be too difficult to apply everywhere.
NAME I don't think you can be that strict, just because of the sender/receiver asymmetry. Just because you received a Proposal doesn't mean that the committer did. I would view the rules in the doc as local guidance for the committer in constructing a Commit. Given that they don't reflect externally-visible behavior, they should probably be downgraded to SHOULD.
NAME that makes sense to me, I'll put up a PR to change to SHOULD