Remove parenthetical about landmark tree sizes

draft-davidben-tls-merkle-tree-certs.md

@@ -880,7 +880,7 @@ The most recent `max_landmarks` landmarks are said to be *active*. Landmarks MUS
 
 If landmarks are allocated incorrectly (e.g. past landmarks change, or `max_landmarks` is inaccurate), there are no security consequences, but some older certificates may fail to validate.
 
-It is RECOMMENDED that landmarks be allocated by picking some `time_between_landmarks` interval, and then appending the latest checkpoint tree size (although any size less or equal to the latest checkpoint tree size is valid) to the sequence, once per interval. If the latest checkpoint tree size is already a landmark, the interval is skipped. `max_landmarks` can then be set to `ceil(max_cert_lifetime / time_between_landmarks)`, where `max_cert_lifetime` is the CA's maximum certificate lifetime. Allocations do not need to be precise, as long as `max_landmarks` is accurate.
+It is RECOMMENDED that landmarks be allocated by picking some `time_between_landmarks` interval, and then appending the latest checkpoint tree size to the sequence, once per interval. If the latest checkpoint tree size is already a landmark, the interval is skipped. `max_landmarks` can then be set to `ceil(max_cert_lifetime / time_between_landmarks)`, where `max_cert_lifetime` is the CA's maximum certificate lifetime. Allocations do not need to be precise, as long as `max_landmarks` is accurate.
 
 Relying parties will locally retain up to `2 * max_landmarks` hashes ({{trusted-subtrees}}) per CA, so `max_landmarks` should be set to balance the delay between landmarks and the amount of state the relying party must maintain. Using the recommended procedure above, a CA with a maximum certificate lifetime of 7 days, allocating a landmark every hour, will have a `max_landmarks` of 168. The client state is then 336 hashes, or 10,752 bytes with SHA-256.