Change:
I think we need to clearly define "FS / PCS with regard to", but once we do that, it seems like a fine phrase. That seems like a good topic for a review / update of the Security Considerations once we have the protocol mostly in shape, for which I have filed .
The not-protocol parts of the document, including security considerations and some of the operational considerations, are mostly untouched since the beginning of this work. As we get the protocol firmed up, we should revisit these parts to make sure they're up to date and give an accurate reflection of the concerns around the protocol.
One particular thing related to this that I noticed is that in the the first sentence: is outdated as (ii) can now also be an all-zero vector, namely if is not required and not set (as introduced in if I'm not mistaken).
I did a review of the Security Considerations and didn't see anything that needs fixing before WGLC. The point that NAME raises appears to have been fixed in some other PR.
Right now, it is possible to send a Commit that covers no proposals. This has the result that the leaf of the sender and its direct path are refreshed, but no other change to the tree is made. (The epoch also advances, of course.) This can be is a useful operation. For example, an Add wipes out the new joiner's direct path, so having the new joiner send a Commit over no proposals would fill in that direct path and make subsequent operations more efficient. We should clarify in some prose that (a) this is possible and (b) why it might be useful.
That works fine. I am a bit bothered by the phrasing regarding properties « with regard to ...». If you can find an alternate phrasing that would be

Discussion:
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. <ins> A member of the group MAY send a Commit that references no proposals at all, which would thus have empty vectors for "updates", "removes", and "adds".  Such a Commit resets the sender's leaf and the nodes along its direct path, and provides forward secrecy and post- compromise security with regard to the sender of the Commit.  An Update proposal can be regarded as a "lazy" version of this operation, where only the leaf changes and intermediate nodes are blanked out. </ins> The "path" field of a Commit message MUST be populated if the Commit covers at least one Update or Remove proposal, i.e., if the length of the "updates" or "removes vectors is greater than zero.  The

In pseudocode, the logic for whether the "path` field is required is as follows: <ins> To summarize, a Commit can have three different configurations, with different uses: An "empty" Commit that references no proposals, which updates the committer's contribution to the group and provides PCS with regard to the committer. An "add-only" Commit that references only Add proposals, in which the path is optional.  Such a commit provides PCS with regard to the committer only if the path field is present. A "full" Commit that references proposals of any type, which provides FS with regard to any removed members and PCS for the committer and any updated members. </ins> A member of the group creates a Commit message and the corresponding Welcome message at the same time, by taking the following steps: