Change:
It probably makes sense to be a little more consistent.
Makes sense. I will do this after the current wave of pull requests have been reviewed and accepted/rejected.
I addressed this issue in PR
Addressed with submitted draft version -04
I don't think that you need to change the grammar.

Discussion:
Abstract <del> This document specifies the Connection ID construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2. </del> <ins> This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2. </ins> <del> A Connection ID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association.  In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple.  If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. </del> <ins> A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association.  In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple.  If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. </ins> 1.

rebinding leads to connection failure, with the resulting cost of a new handshake. <del> This document defines an extension to DTLS to add a connection ID (CID) to the DTLS record layer.  The presence of the connection ID is negotiated via a DTLS extension. </del> <ins> This document defines an extension to DTLS 1.2 to add a CID to the DTLS record layer.  The presence of the CID is negotiated via a DTLS extension. </ins> 2.

3. <del> This document defines a new extension type (connection_id(TBD)), which is used in ClientHello and ServerHello messages. </del> <ins> This document defines the "connection_id" extension, which is used in ClientHello and ServerHello messages. </ins> The extension type is specified as follows.

ClientHello, MUST contain the ConnectionId structure, which carries the CID which the client wishes the server to use when sending messages towards it.  A zero-length value indicates that the client <del> is prepared to send with a connection ID but does not wish the server to use one when sending (alternately, this can be interpreted as the client wishes the server to use a zero-length CID; the result is the same). A server which is willing to use CIDs will respond with its own "connection_id" extension, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value indicates that the server will send with the client's CID but does not wish the client to use a CID (or again, alternately, to use a zero-length CID). </del> <ins> is prepared to send with a CID but does not wish the server to use one when sending (alternately, this can be interpreted as the client wishes the server to use a zero-length CID; the result is the same). A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID (or again, alternately, to use a zero-length CID). </ins> When a session is resumed, the "connection_id" extension is negotiated afresh, not retained from previous connections in the

that it wants to receive as a connection identifier in encrypted records, it is possible for an endpoint to use a globally constant length for such connection identifiers.  This can in turn ease <del> parsing and connection lookup, for example by having the length in question be a compile-time constant.  Implementations, which want to use variable-length CIDs, are responsible for constructing the CID in such a way that its length can be determined on reception.  Note that such implementations must still be able to send connection identifiers of different length to other parties. </del> <ins> parsing and connection lookup, for example by having the length in question be a compile-time constant.  Implementations, which want to use variable-length CIDs, are responsible for constructing the CID in such a way that its length can be determined on reception.  Note that 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 <del> long the Connection ID is. </del> <ins> long the CID is. </ins> <del> 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, because DTLS 1.2 in general does not allow TLS 1.3-style post- handshake messages that do not themselves begin other handshakes. </del> <ins> In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only.  There is no dedicated "CID update" message that allows new CIDs to be established mid-session, because DTLS 1.2 in general does not allow TLS 1.3-style post-handshake messages that do not themselves begin other handshakes. </ins> DTLS peers switch to the new record layer format, i.e., the record layer format containing the CID, when encryption is enabled.

The true content type is inside the encryption envelope, as described below. <del> 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. </del> <ins> When CIDs are 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. </ins> This field contains the byte encoding of a handshake, an alert message, or the raw bytes of the application's data to send.

the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm. <del> The cid value of length indicated with cid_length, as agreed </del> <ins> The CID value of length indicated with cid_length, as agreed </ins> during the exchange. The AEAD-encrypted form of the serialized DTLSInnerPlaintext

This value contains the length information in the outer-header. <del> Value of the negotiated cid.  This field is empty in case a zero- length cid has been negotiated. </del> <ins> Value of the negotiated CID.  This field is empty in case a zero- length CID has been negotiated. </ins> <del> 1 byte field indicating the length of the negotiated cid.  If a zero-length cid has been negotiated, and therefore no cid appears </del> <ins> 1 byte field indicating the length of the negotiated CID.  If a zero-length CID has been negotiated, and therefore no CID appears </ins> on the wire, a cid_length of zero (0) MUST be added. 5. <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 connection_id has zero length we use the term 'connection_id=empty'. </del> <ins> dtls-example2 shows an example exchange where a CID is used uni- directionally from the client to the server.  To indicate that a zero-length CID we use the term 'connection_id=empty'. </ins> Note: In the example exchange the CID is included in the record layer once encryption is enabled.  In DTLS 1.2 only one handshake message

6. <del> The connection id replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime of a DTLS connection.  Every identifier introduces the risk of linkability, as explained in RFC6973. </del> <ins> The CID replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime of a DTLS connection.  Every identifier introduces the risk of linkability, as explained in RFC6973. </ins> <del> In addition, endpoints can use the connection ID to attach arbitrary metadata to each record they receive.  This may be used as a mechanism to communicate per-connection information to on-path observers.  There is no straightforward way to address this with connection IDs that contain arbitrary values; implementations concerned about this SHOULD refuse to use connection ids. </del> <ins> In addition, endpoints can use the CID to attach arbitrary metadata to each record they receive.  This may be used as a mechanism to communicate per-connection information to on-path observers.  There is no straightforward way to address this with CIDs that contain arbitrary values; implementations concerned about this SHOULD refuse to use connection ids. </ins> An on-path adversary, who is able to observe the DTLS protocol exchanges between the DTLS client and the DTLS server, is able to link the observed payloads to all subsequent payloads carrying the same connection id pair (for bi-directional communication).  Without <del> multi-homing or mobility, the use of the connection id is not different to the use of the 5-tuple. </del> <ins> multi-homing or mobility, the use of the CID is not different to the use of the 5-tuple. </ins> With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further