Revert dependency on unmerged kramdown-rfc2629 change

draft-ietf-quic-transport.md

@@ -2576,16 +2576,16 @@ estimation for the new path.
 
 On confirming a peer's ownership of its new address, an endpoint MUST
 immediately reset the congestion controller and round-trip time estimator for
-the new path to initial values (see {{Appendices A.3 and B.3 of QUIC-RECOVERY}})
-unless the only change in the peer's address is its port number.  Because
-port-only changes are commonly the result of NAT rebinding or other middlebox
-activity, the endpoint MAY instead retain its congestion control state and
-round-trip estimate in those cases instead of reverting to initial values.  In
-cases where congestion control state retained from an old path is used on a new
-path with substantially different characteristics, a sender could transmit too
-aggressively until the congestion controller and the RTT estimator have
-adapted. Generally, implementations are advised to be cautious when using
-previous values on a new path.
+the new path to initial values (see Appendices {{A.3<QUIC-RECOVERY}} and
+{{B.3<QUIC-RECOVERY}} of {{QUIC-RECOVERY}}) unless the only change in the peer's
+address is its port number.  Because port-only changes are commonly the result
+of NAT rebinding or other middlebox activity, the endpoint MAY instead retain
+its congestion control state and round-trip estimate in those cases instead of
+reverting to initial values.  In cases where congestion control state retained
+from an old path is used on a new path with substantially different
+characteristics, a sender could transmit too aggressively until the congestion
+controller and the RTT estimator have adapted. Generally, implementations are
+advised to be cautious when using previous values on a new path.
 
 There could be apparent reordering at the receiver when an endpoint sends data
 and probes from/to multiple addresses during the migration period, since the two