More wording improvements, updating sections that got out of date. #662
Conversation
draft-ietf-mls-protocol.md
Outdated
| UpdatePath, with a new LeafNode and set of parent nodes for the sender's | ||
| filtered direct path. For each intermediate node, the UpdatePath contains a new | ||
| public key and encrypted path secret. The nodes are ordered such that each node | ||
| is the ancestor of its predecessor. |
There was a problem hiding this comment.
| is the ancestor of its predecessor. | |
| is the next non-blank ancestor of its predecessor in the filtered direct path. |
There was a problem hiding this comment.
I don't think this is right, the filtered direct path doesn't have blank nodes. Or at least, this way of saying it is not making sense to me right now.
There was a problem hiding this comment.
I can see how it's confusing to say both. How about either "next non-blank ancestor" or "next ancestor in the filtered direct path"?
Alternatively, the filtered direct path already has an order defined:
The direct path of a root is the empty list, and of any other node is the concatenation of that node's parent along with the parent's direct path.
The filtered direct path of a node is obtained from the node's direct path by removing all nodes ... [note this doesn't change the order]
So we could just say that the nodes in the UpdatePath correspond to the nodes in the filtered direct path.
No description provided.