Original text:
2.2. The only cTLS records that are sent in plaintext are handshake <del> records (ClientHello and ServerHello/HRR).  The content type is therefore constant (it is always "handshake"), so we instead set the "content_type" field to a fixed cTLS-specific value to distinguish cTLS plaintext records from encrypted records, TLS/DTLS records, and other protocols using the same 5-tuple. </del>  [[OPEN ISSUE: The profile_id is needed in the ClientHello to inform the server what compression profile to use.  For a ServerHello this

Reviewer comments:
NAME NAME
I wonder whether this works. Here is the solution I came up with URL
yeah that seems more complicated. Is there a reason why this won't work?
IMHO we somehow have to distinguish between three types of message (via the content type): plaintext handshake messages (for the ClientHello, ServerHello/HRR) encrypted cTLS messages, and plaintext alert messages Do I see this wrong?
Agreed. But that's plaintext handshake messages (for the ClientHello, ServerHello/HRR) --> ctls_handshake encrypted cTLS messages, and --> The ordinary DTLS rules plaintext alert messages --> tls alert.
I guess I was thinking about this in a too complicated way. Do you want to use the regular TLS Alert message format? (Fine for me.)
That is my proposal.
I think the logical way to do this would be to register in the . Otherwise, you're setting up a potential collision as more values are added to that registry.
Yes, I agree with that. I'm just talking about the technical approach
OK, then I think this PR might as well add the IANA instruction for that.
I made a separate IANA PR URL
It’s currently not clear how plaintext Alerts are represented. Suggestion: contenttype = ctlsalert
I created a PR to address this issue: URL
NAME why can't they just be the usual content type? What am I missing.
The current text says records (ClientHello and ServerHello/HRR). The content type is therefore constant (it is always handshake), so we instead set the contenttype field to a fixed cTLS-specific value to distinguish cTLS plaintext records from encrypted records, TLS/DTLS records, and other protocols using the same 5-tuple. I'm proposing that: The first sentence (or maybe the second) is not right. We need another for plaintext alerts. I'm not sure what you mean by "the usual content type". cTLS currently does not use TLS's ContentType registry. Instead, the current draft defines a new value to identify these records. If you're proposing to switch cTLS to use the TLS ContentTypes instead ... that seems fine to me. However, the divergence does seem to be deliberate, as explained in the text.
I think this is just an error on my part: You obviously need to be able to send plaintext alerts. The requirement is to be able to demux, but if cTLS alerts are the same, then no need For that reason, I propose to just use TLS's alert type.

Revised text:
2.2. The only cTLS records that are sent in plaintext are handshake  <ins> records (ClientHello and ServerHello/HRR) and alerts. cTLS alerts are the same as TLS alerts and use the same content types.  For handshake records, we set the "content_type" field to a fixed cTLS-specific value to distinguish cTLS plaintext records from encrypted records, TLS/DTLS records, and other protocols using the same 5-tuple. </ins> [[OPEN ISSUE: The profile_id is needed in the ClientHello to inform the server what compression profile to use.  For a ServerHello this