Original text:
of the connection's RTT.  An endpoint computes the following three values: the minimum value observed over the lifetime of the connection (min_rtt), an exponentially-weighted moving average <del> (smoothed_rtt), and the variance in the observed RTT samples (rttvar). </del>  4.1. 4.3. smoothed_rtt is an exponentially-weighted moving average of an <del> endpoint's RTT samples, and rttvar is the endpoint's estimated variance in the RTT samples. </del>  The calculation of smoothed_rtt uses path latency after adjusting RTT samples for ACK delays.  For packets sent in the ApplicationData Implementations MAY experiment with absolute thresholds, thresholds from previous connections, adaptive thresholds, or including RTT <del> variance.  Smaller thresholds reduce reordering resilience and </del>  increase spurious retransmissions, and larger thresholds increase loss detection delay. The PTO period is the amount of time that a sender ought to wait for an acknowledgement of a sent packet.  This time period includes the <del> estimated network roundtrip-time (smoothed_rtt), the variance in the </del>  estimate (4*rttvar), and max_ack_delay, to account for the maximum time by which a receiver might delay sending an acknowledgement. When the PTO is armed for Initial or Handshake packet number spaces,

Reviewer comments:
It's a mean deviation. This has confused at least one reader.
True-ish, but nor is smoothed_rtt a mean. And now you have a variable with a name that bears no semblance to the concept you use to describe it. You could instead play apologist and explain that this isn't a variance in the statistical sense, but variance in a purely colloquial sense.
Section 2 of RFC2988 says "To compute the current RTO, a TCP sender maintains two state variables, SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation)." It does subsequently use the term variance in one spot, but given the original definition is a better one, I'd rather use variation than variance. RFC6298 does the exact same thing, and defines RTTVAR as "round-trip time variation".
In both sentences, minrtt and smoothedrtt are described in technically accurate terms, so I think it makes sense to describe rttvar as a mean deviation, because that's the most technically accurate term. I also understand the need for consistency, so if you have suggestions on how to improve that without removing the technical description, it'd be appreciated.

Revised text:
of the connection's RTT.  An endpoint computes the following three values: the minimum value observed over the lifetime of the connection (min_rtt), an exponentially-weighted moving average  <ins> (smoothed_rtt), and the mean deviation (referred to as "variation" in the rest of this document) in the observed RTT samples (rttvar). </ins> 4.1. 4.3. smoothed_rtt is an exponentially-weighted moving average of an  <ins> endpoint's RTT samples, and rttvar is the variation in the RTT samples, estimated using a mean variation. </ins> The calculation of smoothed_rtt uses path latency after adjusting RTT samples for ACK delays.  For packets sent in the ApplicationData Implementations MAY experiment with absolute thresholds, thresholds from previous connections, adaptive thresholds, or including RTT  <ins> variation.  Smaller thresholds reduce reordering resilience and </ins> increase spurious retransmissions, and larger thresholds increase loss detection delay. The PTO period is the amount of time that a sender ought to wait for an acknowledgement of a sent packet.  This time period includes the  <ins> estimated network roundtrip-time (smoothed_rtt), the variation in the </ins> estimate (4*rttvar), and max_ack_delay, to account for the maximum time by which a receiver might delay sending an acknowledgement. When the PTO is armed for Initial or Handshake packet number spaces,