diff --git a/draft-ietf-avtcore-rtp-over-quic.md b/draft-ietf-avtcore-rtp-over-quic.md
index 6b77fe2..f2977da 100644
--- a/draft-ietf-avtcore-rtp-over-quic.md
+++ b/draft-ietf-avtcore-rtp-over-quic.md
@@ -312,7 +312,7 @@ This document describes the use of QUIC streams and QUIC datagrams as RTP encaps
 
 QUIC {{!RFC9000}} was initially designed to carry HTTP {{?RFC9114}} in QUIC streams, and QUIC streams provide what HTTP application developers require - for example, QUIC streams provide a stateful, connection-oriented, flow-controlled, reliable, ordered stream of bytes to an application. QUIC streams can be multiplexed over a single QUIC connection, using stream IDs to demultiplex incoming messages.
 
-QUIC Datagrams ((!RFC9221}} were developed as a QUIC extension, intended to support applications that do not require reliable delivery of application data. This extension defines two QUIC DATAGRAM frame types (one including a length field, the other not including a length field), and these DATAGRAM frames can co-exist with QUIC STREAM frames within a single QUIC connection, sharing the connection's cryptographic and authentication context, and congestion controller context.
+QUIC Datagrams {{!RFC9221}} were developed as a QUIC extension, intended to support applications that do not require reliable delivery of application data. This extension defines two QUIC DATAGRAM frame types (one including a length field, the other not including a length field), and these DATAGRAM frames can co-exist with QUIC STREAM frames within a single QUIC connection, sharing the connection's cryptographic and authentication context, and congestion controller context.
 
 There is no default relative priority between DATAGRAM frames with respect to each other, and there is no default priority between DATAGRAM frames and QUIC streams. The implementation likely presents an API to allow appplications to assign relative priorities, but this is not mandated by the standard and may not be present in all implementations.