Original text:
such implementations must still be able to send connection identifiers of different length to other parties.  In DTLS 1.2, connection ids are exchanged at the beginning of the DTLS session only.  There is no dedicated "connection id update" message that allows new connection ids to be established mid-session, 4. <del> This extension is applicable for use with DTLS 1.2 and below. dtls- record12 illustrates the record format.  I-D.ietf-tls-dtls13 specifies how to carry the CID in a DTLS 1.3 record. Note that for both record formats, it is not possible to parse the records without knowing how long the Connection ID is. </del>  In order to allow a receiver to determine whether a record has CID or not, connections which have negotiated this extension use a The true content type is inside the encryption envelope, as described below. <del> 5. </del>  <del> When CID is being used, the DTLSCompressed value is first wrapped along with the true content type and padding into a DTLSWrappedCompressed value prior to encryption.  The DTLSWrappedCompressed value is then encrypted. </del>  <del> The value of DTLSCompressed.fragment </del>  <del> The true content type. </del>  <del> Padding, as defined in RFC8446. </del>  In addition, the CID value is included in the MAC calculation for the DTLS record, as shown below.  The MAC algorithm described in The "cid_length" field is a single octet containing the length of the connection ID. <del> 6. </del>  dtls-example2 shows an example exchange where a connection id is used uni-directionally from the client to the server.  To indicate that a contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. <del> 7. </del>  The connection id replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime RFC6347.  It merely provides a more robust mechanism for associating an incoming packet with a stored security context. <del> 8. </del>  IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for

Reviewer comments:
Trying to address URL but also trying to expand the description a bit for clarity.
According URL all records seems to use a . Does this include the ?
Does this PR provide an improvement help? URL
Yes, it clarifies it for me.

Revised text:
such implementations must still be able to send connection identifiers of different length to other parties. <ins> Note that it is not possible to parse the records without knowing how long the Connection ID is. </ins> In DTLS 1.2, connection ids are exchanged at the beginning of the DTLS session only.  There is no dedicated "connection id update" message that allows new connection ids to be established mid-session, 4.  <ins> This specification defines the DTLS 1.2 record layer format and I- D.ietf-tls-dtls13 specifies how to carry the CID in DTLS 1.3. </ins> In order to allow a receiver to determine whether a record has CID or not, connections which have negotiated this extension use a The true content type is inside the encryption envelope, as described below.  <ins> When CID is being used, the content to be sent is first wrapped along with the true content type and padding into a DTLSInnerPlaintext value prior to encryption.  The DTLSInnerPlaintext value is then encrypted. dtls-record12 illustrates the record format. This field contains the byte encoding of a handshake, an alert message, or the raw bytes of the application's data to send. The DTLSInnerPlaintext.type value contains the content type of the record.  This is the non-obfuscated (true) content type. An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type field.  This provides an opportunity for senders to pad any DTLS record by a chosen amount as long as the total stays within record size limits.  See Section 5.4 of for RFC8446 more details.  (Note that TLSInnerPlaintext in that section refers to DTLSInnerPlaintext in this specification.) </ins>  <ins> The outer opaque_type field of a DTLSCiphertext record is always set to the value 25 (tls12_cid).  The actual content type of the record is found in DTLSInnerPlaintext.type after decryption.  By encapsulating the true content type inside the encrypted payload the outer content type (special_type) can be used to signal the new record layer format containing the CID. </ins>  <ins> The DTLSCiphertext.version field describes the protocol being employed.  This document describes an extension to DTLS version 1.2. </ins>  <ins> The DTLSCiphertext.length field indicates the length (in bytes) of the following DTLSCiphertext.encrypted_record, which is the sum of the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm. </ins>  <ins> The AEAD-encrypted form of the serialized DTLSInnerPlaintext structure. Other fields are defined in RFC 6347.  Note that this specification does not make use of the DTLSCompressed structure. </ins> In addition, the CID value is included in the MAC calculation for the DTLS record, as shown below.  The MAC algorithm described in The "cid_length" field is a single octet containing the length of the connection ID.  <ins> 5. </ins> dtls-example2 shows an example exchange where a connection id is used uni-directionally from the client to the server.  To indicate that a contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well.  <ins> 6. </ins> The connection id replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime RFC6347.  It merely provides a more robust mechanism for associating an incoming packet with a stored security context.  <ins> 7. </ins> IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for