gid-ex: Enhance consideration input for epoch length in Gid-reusing GMs

draft-ietf-core-oscore-groupcomm.md

@@ -1944,7 +1944,7 @@ The Group Epoch is set to 0 upon the group's initialization, and is incremented
 
 As an example, a 3-byte Gid can be composed of: i) a 1-byte Group Prefix '0xb1' interpreted as a raw byte string; and ii) a 2-byte Group Epoch interpreted as an unsigned integer ranging from 0 to 65535. Then, after having established the Common Context 61532 times in the group, its Gid will assume value '0xb1f05c'.
 
-Using an immutable Group Prefix for a group assumes that enough time elapses before all possible Group Epoch values are used, i.e., before the Group Manager terminates the group or starts reassigning Gid values to the group (see {{sec-group-key-management}}). Thus, the expected highest rate for addition/removal of group members and consequent group rekeying should be taken into account for a proper dimensioning of the Group Epoch size.
+Using an immutable Group Prefix for a group with a Group Manager that can not reassign Gid values ({{sec-group-key-management}}) limits the total number of rekeyings. With a Group Manager that does reassign Gid values, it limits the maximum active number of rekeyings that an observation can persist through. In either case, the group epoch size needs to be chosen depending on the expected rate of rekeyings.
 
 As discussed in {{ssec-gid-collision}}, if endpoints are deployed in multiple groups managed by different non-synchronized Group Managers, it is possible that Group Identifiers of different groups coincide at some point in time. In this case, a recipient has to handle coinciding Group Identifiers, and has to try using different Security Contexts to process an incoming message, until the right one is found and the message is correctly verified. Therefore, it is favorable that Group Identifiers from different Group Managers have a size that result in a small probability of collision. How small this probability should be is up to system designers.