Original text:
When receiving a datagram with the tls12_cid content type, the new MAC computation defined in mac MUST be used.  When receiving a <del> datagram with the RFC 6347-defined record format the MAC calculation </del>  defined in Section 4.1.2 of RFC6347 MUST be used. 4. The MAC calculation follows the process described in mac. <del> The true content type is inside the encryption envelope, as </del>  described below. Plaintext records are not impacted by this extension.  Hence, the 1 byte field indicating the length of the negotiated CID. <del> The length (in bytes) of the serialised DTLSInnerPlaintext (two- </del>  byte integer).  The length MUST NOT exceed 2^14. 8 bytes of 0xff 6. When a record with a CID is received that has a source address <del> different than the one currently associated with the DTLS connection, </del>  the receiver MUST NOT replace the address it uses for sending records to its peer with the source address specified in the received <del> datagram unless the following three conditions are met: </del>  The received datagram has been cryptographically verified using the DTLS record layer processing procedures. 10. <del> This document requests three actions by IANA. </del>  10.1.

Reviewer comments:
FWIW, I think some of these are gratuitous but they're not harmful.
URL Lars Eggert has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: All comments below are about potential very minor issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools, so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 3, paragraph 10, nit: Broken kramdown reference? Section 1, paragraph 4, nit: This document defines an extension to DTLS 1.2 to add a CID to the This document defines an extension to DTLS 1.2 to add a Connection ID (CID) to the ++++++++++ ++++++ Section 3, paragraph 7, nit: for example by having the length in question be a compile-time for example, by having the length in question be a compile-time + Section 3, paragraph 7, nit: different length to other parties. Implementations that want to use variable-length CIDs are responsible for constructing the CID in such different lengths to other parties. Implementations that want to use + variable-length CIDs are responsible for constructing the CIDs in such + Section 3, paragraph 12, nit: datagram with the RFC 6347-defined record format the MAC calculation datagram with the RFC 6347-defined record format, the MAC calculation + Section 4, paragraph 6, nit: The true content type is inside the encryption envelope, as - - The real content type is inside the encryption envelope, as ++ Section 6, paragraph 2, nit: datagram unless the following three conditions are met: datagram, unless all of the following three conditions are met: + +++++++ Section 10, paragraph 2, nit: This document requests three actions by IANA. ^^ This document requests three actions from IANA. ^^^^ Section 4, paragraph 17, nit: If 'type' is a classification term, 'a' is not necessary. Use "type of". (The phrases 'kind of' and 'sort of' are informal if they mean 'to some extent'.) Section 4, paragraph 19, nit: Make sure that 'use to' is correct. For habitual actions in the past or to mean 'accustomed to', use "used to". Section 5, paragraph 6, nit: Do not mix variants of the same word ('serialise' and 'serialize') within a single text. Section 6, paragraph 2, nit: Did you mean 'different "from"? 'Different than' is often considered colloquial style. Section 6, paragraph 2, nit: Consider using "all the". "Appendix A.", paragraph 1, nit: Maybe you need to remove the second determiner so that only "THE" or "THIS" is left. "Appendix A.", paragraph 29, nit: 'a la' is an imported foreign expression, which originally has a diacritic. Consider using "à la" "Appendix B.", paragraph 1, nit: Maybe you need to remove the second determiner so that only "THE" or "THIS" is left. "Appendix C.", paragraph 1, nit: Use a comma before 'and' if it connects two independent clauses (unless they are closely connected and short). These reference issues exist in the document: No reference entries found for: [ChangeCipherSpec], [length], [lengthofpadding], [URL], [draft-rescorla-tls-dtls-connection-id-00], [cid_length], [URL] Uncited references: [RFC5246] Obsolete reference to RFC5246, obsoleted by RFC8446 These URLs in the document did not return content: URL URL URL

Revised text:
When receiving a datagram with the tls12_cid content type, the new MAC computation defined in mac MUST be used.  When receiving a  <ins> datagram with the RFC 6347-defined record format, the MAC calculation </ins> defined in Section 4.1.2 of RFC6347 MUST be used. 4. The MAC calculation follows the process described in mac.  <ins> The real content type is inside the encryption envelope, as </ins> described below. Plaintext records are not impacted by this extension.  Hence, the 1 byte field indicating the length of the negotiated CID.  <ins> The length (in bytes) of the serialized DTLSInnerPlaintext (two- </ins> byte integer).  The length MUST NOT exceed 2^14. 8 bytes of 0xff 6. When a record with a CID is received that has a source address  <ins> different from the one currently associated with the DTLS connection, </ins> the receiver MUST NOT replace the address it uses for sending records to its peer with the source address specified in the received  <ins> datagram, unless the following three conditions are met: </ins> The received datagram has been cryptographically verified using the DTLS record layer processing procedures. 10.  <ins> This document requests three actions from IANA. </ins> 10.1.