diff --git a/draft-beck-tls-trust-anchor-ids.md b/draft-beck-tls-trust-anchor-ids.md
index c9fd431..bcc7708 100644
--- a/draft-beck-tls-trust-anchor-ids.md
+++ b/draft-beck-tls-trust-anchor-ids.md
@@ -447,7 +447,7 @@ Each of these categories carries a different fingerprinting exposure:
 
 Trust anchors that do not participate are not revealed by this extension. However, they have some fingerprinting exposure due to being trusted. Given a certification path, an authenticating party can probe whether the relying party trusts the trust anchor by seeing if the relying party accepts it.
 
-Trust anchor identifiers sent in response to the authenticating party can only be observed actively. That is, the authenticating party could vary its list and observe how the client responds, in order to probe for the client's trust anchor list. This is similar to the baseline exposure, except that the trust anchor can be probed by only knowing the trust anchor identifier.
+Trust anchor identifiers sent in response to the authenticating party can only be observed actively. That is, the authenticating party could vary its list and observe how the client responds, in order to probe for the client's trust anchor list. This is similar to the exposure of trust anchors not participating in this extension, except that the trust anchor can be probed by only knowing the trust anchor identifier.
 
 Trust anchor identifiers sent unconditionally can be observed passively. This mode is analogous to the `certificate_authorities` extension. Relying parties SHOULD NOT unconditionally advertise trust anchor lists that are unique to an individual user. Rather, unconditionally-advertised lists SHOULD be empty or computed only from the trust anchors common to the relying party's anonymity set ({{Section 3.3 of !RFC6973}}).