Original text:
10. <del> IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for 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 and to include this document as an additional reference for the registry. </del>  Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document applicable to TLS, and its usage for DTLS 1.3 is described in I- D.ietf-tls-dtls13. <del> IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType Registry".  The tls12_cid ContentType is only applicable to DTLS 1.2. </del> 

Reviewer comments:
Tom Petch's review: URL
URL Some editorial quirks s.2 lacks the boiler plate of RFC8174 s.3 I found this unclear until I had understood it all (or perhaps I do not understand it) "URL again, alternately, to use a zero-length CID)." This suggests that a zero length CID is valid in Application Data which later text seems to contradict; otherwise I cannot see what this is saying. " If DTLS peers have negotiated the use of a CIDs using the ClientHello and the ServerHello messages " arguably sending a zero CID and receiving a zero CID is a successful Hello negotiation perhaps " If DTLS peers have negotiated the use of a non-zero CID in at least one direction, using the ClientHello and the ServerHello messages" "The DTLS peers determine whether incoming and outgoing messages need.." seems not to cater for unidirectional CIDs; perhaps "The DTLS peers determine whether incoming or outgoing, or both, messages need.. " s.4 /always recieve CIDs/always receive CIDs/ s.5.1 "the with Encrypt-then-MAC processing described in [RFC7366]." I do not understand why 'with' is needed s.5.2 ditto s.8 /this aspects SHOULD refuse/these aspects SHOULD refuse/ s.10 I would find this clearer as three sections for the three IANA actions new column for ExtensionType new value for ExtensionType new value for ContentType " IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in [RFC5246],.." well no; whatever you think of RFC8447 the name has changed " IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, defined in [RFC5246],.." or, if you are picky (which I am not), IANA is requested to allocate an entry to the existing "TLS "ExtensionType Values" registry, defined in [RFC5246], and renamed by RFC8447 An extra column is added but I cannot see what value should be placed in that column for existing entries. "The tls12_cid ContentType is only applicable to DTLS 1.2." Good information but I struggle to see what IANA will do with it; I see nowhere for it to go. Tom Petch >

Revised text:
10.  <ins> This document requests three actions by IANA. 10.1. IANA is requested to add an extra column to the "TLS ExtensionType Values" registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. 10.2. IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, for connection_id(TBD1) as described in the table below. </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document applicable to TLS, and its usage for DTLS 1.3 is described in I- D.ietf-tls-dtls13.  <ins> 10.3. IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType" registry.  The tls12_cid ContentType is only applicable to DTLS 1.2. </ins>