Change:
Francesca says I am uncertain whether this document is the right place to place restrictions on IANA for this purpose beyond what has already been done elsewhere. Maybe there is a chance to do something in the TLS 1.3 update.
I added some text to the PR.
Since got merged, should this issue be closed now?
Thank you for this document. Please find some minor comments below. Francesca section 2. Conventions and Terminology FP: Please spell out that network byte order (most significant byte first) is used throughout the document. Once the client has transmitted the ClientHello message, it expects to see a HelloRetryRequest or a ServerHello from the server. However, if the server's message is lost, the client knows that either the ClientHello or the response from the server has been lost and retransmits. When the server receives the retransmission, it knows to retransmit. FP: It would be good to mention retransmission max times here. /+----------------+ /+-------+--------+ The value for the "DTLS-OK" column is "Y". IANA is requested to reserve the content type range 32-63 so that content types in this range are not allocated. FP: IANA is asked to reserve 32-63, but I could not see any explanation for that. I would like to see it justified in section 4.1 or in the respective IANA section. fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer. FP: First time PMTU appears, please expand and add reference. performing PMTU discovery, whether via [RFC1191] or [RFC4821] mechanisms. In particular: FP: I think this is missing areference to RFC 8201 since IPv6 is mentioned below. Any TLS cipher suite that is specified for use with DTLS MUST define limits on the use of the associated AEAD function that preserves margins for both confidentiality and integrity. That is, limits MUST be specified for the number of packets that can be authenticated and for the number of packets that can fail authentication before a key update is required. Providing a reference to any analysis upon which values are based - and any assumptions used in that analysis - allows limits to be adapted to varying usage conditions. FP: This seems important enough that it should be highlighted for the experts reviewing the registration. I see that URL has a number of notes, maybe that would be enough, or maybe add it (as an update?) to RFC 8447? zero length vector (i.e., a single zero byte length field). FP: I suggest using TLS 1.3 terminology of "zero-length vector (i.e., a zero-valued single byte length field)" flow shown in Figure 11 if the client does not send the ACK message FP: s/11/12
Addressed in
LGTM with some suggested nits

Discussion:
for convenience we use the term HelloRetryRequest throughout this document as if it were a distinct message. <ins> DTLS 1.3 uses network byte order (big-endian) format for encoding messages based on the encoding format defined in TLS13 and earlier (D)TLS specifications. </ins> The reader is also assumed to be familiar with I-D.ietf-tls-dtls- connection-id as this document applies the CID functionality to DTLS 1.3.

demux shows this demultiplexing procedure graphically taking DTLS 1.3 and earlier versions of DTLS into account. <ins> Note: The optimized DTLS header format shown in cid_hdr, which does not carry the Content Type in the Unified Header format, requires a different demultilexing strategy compared to what was used in previous DTLS versions where the Content Type was conveyed in every record.  As described in demux, the first byte determines how an incoming DTLS record is demultiplexed.  The first 3 bits of the first byte distinguish a DTLS 1.3 encrypted record from record types used in previous DTLS versions and plaintext DTLS 1.3 record types. Hence, the range 32 (0b0010 0000) to 63 (0b0011 1111) needs to be excluded from future allocations by IANA to avoid demultiplexing problems; see iana-considerations. </ins> 4.2. DTLS uses an explicit or partly explicit sequence number, rather than

DTLS messages MAY be fragmented into multiple DTLS records.  Each DTLS record MUST fit within a single datagram.  In order to avoid IP <del> fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer.  For more information about PMTU issues see pmtu- issues. </del> <ins> fragmentation, clients of the DTLS record layer SHOULD <<<<<<< HEAD attempt to size records so that they fit within any PMTU estimates obtained from the record layer.  For more information about PMTU issues see pmtu-issues.  ======= attempt to size records so that they fit within any Path MTU (PMTU) estimates obtained from the record layer.  >>>>>>> hannestschofenig-patch-40 </ins> Multiple DTLS records MAY be placed in a single datagram.  Records are encoded consecutively.  The length field from DTLS records

upper layer protocol of the error. The DTLS record layer SHOULD NOT interfere with upper layer protocols <del> performing PMTU discovery, whether via RFC1191 or RFC4821 mechanisms. In particular: </del> <ins> performing PMTU discovery, whether via RFC1191 and RFC4821 for IPv4 or via RFC8201 for IPv6.  In particular: </ins> Where allowed by the underlying transport protocol, the upper layer protocol SHOULD be allowed to set the state of the DF bit

The cookie extension is defined in Section 4.2.2 of TLS13.  When sending the initial ClientHello, the client does not have a cookie yet.  In this case, the cookie extension is omitted and the <del> legacy_cookie field in the ClientHello message MUST be set to a zero length vector (i.e., a single zero byte length field). </del> <ins> legacy_cookie field in the ClientHello message MUST be set to a zero- length vector (i.e., a zero-valued single byte length field). </ins> When responding to a HelloRetryRequest, the client MUST create a new ClientHello message following the description in Section 4.1.2 of

In the first case the use of the ACK message is optional because the peer will retransmit in any case and therefore the ACK just allows for selective retransmission, as opposed to the whole flight <del> retransmission in previous versions of DTLS.  For instance in the flow shown in dtls-key-update if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is </del> <ins> retransmission in previous versions of DTLS.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is </ins> recommended. The use of the ACK for the second case is mandatory for the proper

the "DTLS-OK" columns are "Y". IANA is requested to add this RFC as a reference to the TLS Cipher <del> Suite Registry. </del> <ins> Suite Registry along with the following Note: </ins>