Original text:
multi-homing or mobility, the use of the CID is not different to the use of the 5-tuple.  With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further privacy concerns.  The lack of a CID update mechanism makes this IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for <del> connection_id(TBD1) defined in this document. </del>  IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType <del> Registry". </del> 

Reviewer comments:
... IANA consideration section based on issue raised by Sean (see URL) ... Security consideration section based on issue raised by Thomas (see URL)
This PR aims to replace PR & PR
A couple of tweaks are needed for the IANA Considerations Section: Based on input from the IANA TLS DEs, it seems like we need a column added to the TLS ExtensionType Values registry to indicate that an extension is DTLS-only. The column values for TLS 1.3 and Recommended are missing. Suggest blank for TLS 1.3 and N for Recommended. Add a note to say that connectionid is DTLS1.2 only. Add instructions for IANA to assign "Y" to DTLS-okay column for tls12cid content type.
That results in "DTLS only" for TLS extensions and "DTLS-OK" for TLS parameters. I'm not sure, if that just represents more the "current" usage than the "logic" behind it. I would be afraid, that this will hold up other ideas, which doesn't match that "only for extensions / ok for parameters" pattern.
I am not sure what "DTLS-OK" for TLS parameters means
For TLS parameters there's a column "DTLS-OK", And for TLS extensions a column "DTLS only". Does this explain my comment?
We added text to the draft-ietf-tls-dtls-connection-id-06 about the IANA consideration section. I believe this issue is closed.

Revised text:
multi-homing or mobility, the use of the CID is not different to the use of the 5-tuple. <ins> An on-path adversary can also black-hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. </ins> With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further privacy concerns.  The lack of a CID update mechanism makes this IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for  <ins> connection_id(TBD1) as described in the table below.  IANA is requested to add an extra column to the TLS ExtensionType Values registry to indicate whether an extension is only applicable to DTLS. Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document describes an extension for DTLS 1.2 only; it is not to TLS (1.3). The DTLS 1.3 functionality is described in I-D.ietf-tls-dtls13. </ins> IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType  <ins> Registry".  The tls12_cid ContentType is only applicable to DTLS 1.2. </ins>