Original text:
The two low bits (0x03) include the low order two bits of the epoch. <del> Variable length CID.  The CID concept is described in DTLS-CID. An example can be found in connection-id-example. </del>  The low order 8 or 16 bits of the record sequence number.  This value is 16 bits if the S bit is set to 1, and 8 bits if the S bit association identifiers and applications must arrange to multiplex between associations.  With UDP, the host/port number is used to look up the appropriate security association for incoming records. <del> However, the CID extension defined in DTLS-CID adds an association identifier to DTLS records. </del>  Some transports, such as DCCP RFC4340, provide their own sequence numbers.  When carried over those transports, both the DTLS and the 9. If the client and server have negotiated the "connection_id" <del> extension DTLS-CID, either side can send a new CID which it wishes the other side to use in a NewConnectionId message. </del>  %%% Connection ID Management enum { cid_immediate(0), cid_spare(1), (255) } ConnectionIdUsage; Below is an example exchange for DTLS 1.3 using a single CID in each direction. <del> Note: The connection_id extension is defined in DTLS-CID, which is used in ClientHello and ServerHello messages. </del>  If no CID is negotiated, then the receiver MUST reject any records it receives that contain a CID. concerned about this form of attack can discard out-of-epoch records. The security and privacy properties of the CID for DTLS 1.3 builds on <del> top of what is described in DTLS-CID.  There are, however, several improvements: </del>  The use of the Post-Handshake message allows the client and the server to update their CIDs and those values are exchanged with

Reviewer comments:
I-D.ietf-tls-dtls-connection-id became a normative reference Removed duplicate reference to I-D.ietf-tls-dtls-connection-id.

Revised text:
The two low bits (0x03) include the low order two bits of the epoch.  <ins> Variable length CID.  The CID concept is described in I-D.ietf- tls-dtls-connection-id.  An example can be found in connection-id- example. </ins> The low order 8 or 16 bits of the record sequence number.  This value is 16 bits if the S bit is set to 1, and 8 bits if the S bit association identifiers and applications must arrange to multiplex between associations.  With UDP, the host/port number is used to look up the appropriate security association for incoming records.  <ins> However, the CID extension defined in I-D.ietf-tls-dtls-connection-id adds an association identifier to DTLS records. </ins> Some transports, such as DCCP RFC4340, provide their own sequence numbers.  When carried over those transports, both the DTLS and the 9. If the client and server have negotiated the "connection_id"  <ins> extension I-D.ietf-tls-dtls-connection-id, either side can send a new CID which it wishes the other side to use in a NewConnectionId message. </ins> %%% Connection ID Management enum { cid_immediate(0), cid_spare(1), (255) } ConnectionIdUsage; Below is an example exchange for DTLS 1.3 using a single CID in each direction.  <ins> Note: The connection_id extension is defined in I-D.ietf-tls-dtls- connection-id, which is used in ClientHello and ServerHello messages. </ins> If no CID is negotiated, then the receiver MUST reject any records it receives that contain a CID. concerned about this form of attack can discard out-of-epoch records. The security and privacy properties of the CID for DTLS 1.3 builds on  <ins> top of what is described in I-D.ietf-tls-dtls-connection-id.  There are, however, several improvements: </ins> The use of the Post-Handshake message allows the client and the server to update their CIDs and those values are exchanged with