Original text:
6.3.1. <del> Content to be encrypted is encoded in an PrivateContentTBE structure. </del>  The "padding" field is set by the sender, by first encoding the content (via the "select") and the "auth" field, then appending the contains an object of the following form, with the values used to identify the key and nonce: <del> When decoding an PrivateContentTBE, the application MUST check that </del>  the FramedContentAuthData is valid. It is up to the application to decide what "authenticated_data" to are represented as absolute times, measured in seconds since the Unix epoch (1970-01-01T00:00:00Z).  Applications MUST define a maximum total lifetime that is acceptable for a LeafNode, and reject any <del> LeafNode where the total lifetime is longer than this duration. </del>  In the case where the leaf node was inserted into the tree via a Commit message, the "parent_hash" field contains the parent hash for the client, e.g., a proposal, a commit, or a ratchet tree of the group the client is joining, it is RECOMMENDED that the client verifies that the current time is within the range of <del> the "lifetime" field. </del>  Verify that the extensions in the LeafNode are supported by checking that the ID for each extension in the "extensions" field If encoding as PublicMessage, compute the "membership_tag" value using the "membership_key". <del> If encoding as an PrivateMessage, encrypt the message using the </del>  "sender_data_secret" and the next (key, nonce) pair from the sender's handshake ratchet.

Reviewer comments:
URL
:+1: Thank you very much for all of the explicitly worked examples. What is the reason for MUST vs RECOMMENDED difference in the two different circumstances when validating the `lifetime` field? Consider adding a platitude about communicating nodes SHOULD use some method of time synchronization... "top of these basic mechanism" -> "top of these basic mechanisms" (or maybe "top of this basic mechanism") "in an PrivateContentTBE structure" -> "in a PrivateContentTBE structure"

Revised text:
6.3.1.  <ins> Content to be encrypted is encoded in a PrivateContentTBE structure. </ins> The "padding" field is set by the sender, by first encoding the content (via the "select") and the "auth" field, then appending the contains an object of the following form, with the values used to identify the key and nonce:  <ins> When decoding a PrivateContentTBE, the application MUST check that </ins> the FramedContentAuthData is valid. It is up to the application to decide what "authenticated_data" to are represented as absolute times, measured in seconds since the Unix epoch (1970-01-01T00:00:00Z).  Applications MUST define a maximum total lifetime that is acceptable for a LeafNode, and reject any  <ins> LeafNode where the total lifetime is longer than this duration.  In order to avoid disagreements about whether a LeafNode has a valid lifetime, the clients in a group SHOULD maintain time synchronization (e.g., using the Network Time Protocol RFC5905). </ins> In the case where the leaf node was inserted into the tree via a Commit message, the "parent_hash" field contains the parent hash for the client, e.g., a proposal, a commit, or a ratchet tree of the group the client is joining, it is RECOMMENDED that the client verifies that the current time is within the range of  <ins> the "lifetime" field.  (This check is not mandatory because the LeafNode might have expired in the time between when the message was sent and when it was received.) </ins> Verify that the extensions in the LeafNode are supported by checking that the ID for each extension in the "extensions" field If encoding as PublicMessage, compute the "membership_tag" value using the "membership_key".  <ins> If encoding as a PrivateMessage, encrypt the message using the </ins> "sender_data_secret" and the next (key, nonce) pair from the sender's handshake ratchet.