jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-tls-dtls13

Commentary: As far as referring to the snake case in the main body , I went and looked at RFC 8446 and it does not refer to the snake case . I tend to think that if we make the change in 5.2 and A.2 , that should be enough breadcrumbs for people to figure it out . I put them in the same order as they are in the registry and moved up newsessionticket . Triple check this change please . 
 This I - D registers two TLS HandshakeTypes . All of the other fields in the registry use snake_case .
Paragraph (version A):
IANA is requested to allocate two values in the "TLS Handshake Type"
registry, defined in TLS13, for RequestConnectionId (TBD), and
NewConnectionId (TBD), as defined in this document.  The value for
the "DTLS-OK" columns are "Y".
Paragraph (version B):
IANA is requested to allocate two values in the "TLS Handshake Type"
registry, defined in TLS13, for request_connection_id (TBD), and
new_connection_id (TBD), as defined in this document.  The value for
the "DTLS-OK" columns are "Y".
Draft: draft-ietf-tls-dtls13

Commentary: The middle two commits should be looked at individually . Optional - ACK can be used ( as in Figure 12 ) to short - circuit the retransmit timer in addition to selective acknowledgment . 
 ( Looks like I still do n't understand the kramdown reference behavior . )
Paragraph (version A):
The following is an example of a handshake with lost packets and
retransmissions.  Note that the client sends an empty ACK message
because it can only acknowledge Record 1 sent by the server once it
has processed messages in Record 0 needed to establish epoch 2 keys,
which are needed to encrypt or decrypt messages found in Record 1.
ack-msg provides the necessary background details for this
interaction.  Note: for simplicity we are not re-setting record
numbers in this diagram, so "Record 1" is really "Epoch 2, Record 0,
etc.".
Paragraph (version B):
The following is an example of a handshake with lost packets and
retransmissions.  Note that the client sends an empty ACK message
because it can only acknowledge Record 2 sent by the server once it
has processed messages in Record 0 needed to establish epoch 2 keys,
which are needed to encrypt or decrypt messages found in Record 2.
ack-msg provides the necessary background details for this
interaction.  Note: for simplicity we are not re-setting record
numbers in this diagram, so "Record 1" is really "Epoch 2, Record 0,
etc.".
Draft: draft-ietf-tls-dtls13

Commentary: How did we manage to go so far without noticing this !
Paragraph (version A):
The following is an example of a handshake with lost packets and
retransmissions.  Note that the client sends an empty ACK message
because it can only acknowledge Record 1 sent by the server once it
has processed messages in Record 0 needed to establish epoch 2 keys,
which are needed to encrypt or decrypt messages found in Record 1.
ack-msg provides the necessary background details for this
interaction.
Paragraph (version B):
The following is an example of a handshake with lost packets and
retransmissions.  Note that the client sends an empty ACK message
because it can only acknowledge Record 1 sent by the server once it
has processed messages in Record 0 needed to establish epoch 2 keys,
which are needed to encrypt or decrypt messages found in Record 1.
ack-msg provides the necessary background details for this
interaction.  Note: for simplicity we are not re-setting record
numbers in this diagram, so "Record 1" is really "Epoch 2, Record 0,
etc.".
Draft: draft-ietf-tls-dtls13

Commentary: Zaheduzzaman Sarker wrote -need to add text 
 I do n't actually understand the ask here . Why would it matter ? 
 I believe he wants us to note that when an invalid record is received and silently discarded then it does not impact timers in any way . It would be surprising if it did but do we want to add a sentence about that ? 
 Since we have a dedicated section for " handling invalid records " that does allow for things other than silent discard , it makes sense to mention the lack of effect on timers . " [ ... ] however , an error MAY be logged for diagnostic purposes . In no case does an invalid record affect pending retransmission timers . " ? 
 I 'm not sure I agree , but I something .
Paragraph (version B):
Note that because invalid records are rejected at a layer lower than
the handshake state machine, they do not affect pending
retransmission timers.
Draft: draft-ietf-tls-dtls13

Commentary: = = COMMENTS = = -- Section 3 -- s / TLS can not be used directly in datagram environments / TLS can not be used directly over a datagram transport/ ? [ Hannes ] DTLS is also used over non - IP - based networks ( e.g. LoRaWAN , NB IoT ,   ) and " datagram transport " . What would be the right term to describe " environments " that include transport layer protocols like UDP as well as those non - IP - based networks ? Bullet 2 ) s / to enable reassembly in the correct order / to enable reordering/ ? [ Hannes ] The complete sentence is : " The DTLS handshake includes message sequence numbers to enable reassembly in the correct order in case datagrams are lost or reordered . " I believe that saying sequence numbers enable reassembly in the correct order is correct . -- Section 3.1 -- Should there be a hint to a maximum retry count ? [ Hannes ] There will be a retry count in an implementation . Do we need to say that if we do n't have a number to suggest ? Not sure . -- Section 3.3 -- I understand the motivation ( and no need to reply ) , but , sigh ... implementing frag / reassembly above the transport layer ... [ Hannes ] Seems to be common these days . Examples : CoAP , and QUIC 
 I do n't think I found the PR to match up with the " pr - exists " label ; could I get a pointer ? 
 My bad .
Paragraph (version A):
The TLS handshake is a lock-step cryptographic protocol.  Messages
must be transmitted and received in a defined order; any other
order is an error.  The DTLS handshake includes message sequence
numbers to enable reassembly in the correct order in case
datagrams are lost or reordered.
Paragraph (version B):
The TLS handshake is a lock-step cryptographic protocol.  Messages
must be transmitted and received in a defined order; any other
order is an error.  The DTLS handshake includes message sequence
numbers to enable fragmented message reassembly and in-order
delivery in case datagrams are lost or reordered.
Draft: draft-ietf-tls-dtls13

Commentary: The text is good for me . 
 LGTM , but we should confirm on the list . This definitely helps , thanks . It does n't completely eliminate the possibility of QUIC - LB catastrophic failure , but it makes things way better .
Paragraph (version B):
DTLS clients which do not want to receive a Connection ID SHOULD
still offer the "connection_id" extension unless there is an
application profile to the contrary.  This permits a server which
wants to receive a CID to negotiate one.
Draft: draft-ietf-tls-dtls13

Commentary: [ section 4.4 ] " respectively " -"respectively . " Could a DTLS implementation packetize to a min - MTU for an IP version and avoid all pMTU issues ? Such a strategy would probably be poor for IPv4 but might be acceptable for IPv6 communications . [ section 4.5.3 ] " MUST NOT used " -"MUST NOT be used " [ section 5.8.4 ] " NOT have send " -"NOT send " , I think [ section 6 ] " which are needed to encrypt to decrypt " ? 
 and avoid all pMTU issues ? Such a strategy would probably be poor for IPv4 but might be acceptable for IPv6 communications . I 'm reluctant to recommend this , given that we know one can run into situations where there is more overhead due to tunnels , etc .
Paragraph (version B):
Note that DTLS does not defend against spoofed ICMP messages;
implementations SHOULD ignore any such messages that indicate PMTUs
below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively.
Paragraph (version A):
The AEAD_AES_128_CCM_8 AEAD, as used in TLS_AES_128_CCM_8_SHA256,
does not have a limit on the number of records that fail
authentication that both limits the probability of forgery by the
same amount and does not expose implementations to the risk of denial
of service; see ccm-short.  Therefore, TLS_AES_128_CCM_8_SHA256 MUST
NOT used in DTLS without additional safeguards against forgery.
Implementations MUST set usage limits for AEAD_AES_128_CCM_8 based on
an understanding of any additional forgery protections that are used.
Paragraph (version B):
The AEAD_AES_128_CCM_8 AEAD, as used in TLS_AES_128_CCM_8_SHA256,
does not have a limit on the number of records that fail
authentication that both limits the probability of forgery by the
same amount and does not expose implementations to the risk of denial
of service; see ccm-short.  Therefore, TLS_AES_128_CCM_8_SHA256 MUST
NOT be used in DTLS without additional safeguards against forgery.
Implementations MUST set usage limits for AEAD_AES_128_CCM_8 based on
an understanding of any additional forgery protections that are used.
Draft: draft-ietf-tls-dtls13

Commentary: Discuss the properties needed of cookies and some ancillary operational procedures , as well as mentioning that the DTLS record replay protection mechanism and 0 - RTT replay protection mechanism play different roles and can not substitute for each other .
Paragraph (version A):
DTLS implementations MUST NOT update the address they send to in
response to packets from a different address unless they first
perform some reachability test; no such test is defined in this
specification.  Even with such a test, an active 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.
Paragraph (version B):
it MUST NOT be possible for anyone other than the issuing entity
to generate cookies that are accepted as valid by that entity.
This typically entails the use of a keyed MAC and secret key.
Paragraph (version B):
cookie generation and verification are triggered by
unauthenticated parties, and as such their resource consumption
needs to be restrained in order to avoid having the cookie-
exchange mechanism itself serve as a DoS vector.
Paragraph (version B):
When cookies are generated using a keyed MAC (such as HMAC with a
cryptographic hash function), it should be possible to rotate the
associated secret key, so that temporary compromise of the key does
not permanently compromise the integrity of the cookie-exchange
mechanism.  Though this secret is not as high-value as, e.g., a
session-ticket-encryption key, rotating the cookie-generation key on
a similar timescale would ensure that the key-rotation functionality
is exercised regularly and thus in working order.
Paragraph (version B):
The cookie exchange provides address validation during the initial
handshake.  DTLS with connection IDs allow for endpoint addresses to
change during the association; any such updated addresses are not
covered by the cookie exchange during the handshake.  DTLS
implementations MUST NOT update the address they send to in response
to packets from a different address unless they first perform some
reachability test; no such test is defined in this specification.
Even with such a test, an active 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.
Paragraph (version B):
TLS 1.3 requires replay protection for 0-RTT data (or rather, for
connections that use 0-RTT data; see Section 8 of TLS13).  DTLS
provides an optional per-record replay-protection mechanism, since
datagram protocols are inherently subject to message reordering and
replay.  These two replay-protection mechanisms are orthogonal, and
neither mechanism meets the requirements for the other.
Draft: draft-ietf-tls-dtls13

Commentary: Clarify that being scoped to the current flight goes hand in hand with the implicit ACK behavior for an entire flight .
Paragraph (version A):
During the handshake, ACKs only cover the current outstanding flight
(this is possible because DTLS is generally a lockstep protocol).
Thus, an ACK from the server would not cover both the ClientHello and
the client's Certificate.  Implementations can accomplish this by
clearing their ACK list upon receiving the start of the next flight.
Paragraph (version B):
During the handshake, ACKs only cover the current outstanding flight
(this is possible because DTLS is generally a lockstep protocol).  In
particular, receiving a message from a handshake flight implicitly
acknowledges all messages from the previous flight(s).  Accordingly,
an ACK from the server would not cover both the ClientHello and the
client's Certificate, because the ClientHello and client Certificate
are in different flights.  Implementations can accomplish this by
clearing their ACK list upon receiving the start of the next flight.
Draft: draft-ietf-tls-dtls13

Commentary: It is not the same as TLS 1.3 , as previously stated , because DTLS 1.3 does not support the compatibility mode . 
 It seems a natural consequence of not having compatibility mode , but is probably worth running by the list just to cover all bases .
Paragraph (version A):
Same as for TLS 1.3.
Paragraph (version B):
Versions of TLS and DTLS before version 1.3 supported a "session
resumption" feature which has been merged with pre-shared keys in
version 1.3.  A client which has a cached session ID set by a pre-
DTLS 1.3 server SHOULD set this field to that value.  Otherwise,
it MUST be set as a zero-length vector (i.e., a zero-valued single
byte length field).
Draft: draft-ietf-tls-dtls13

Commentary: I have re - drawn the figure to take Ekr 's comments into account . I hope the new figure is better . 
 LGTM
Paragraph (version B):
demux shows this demultiplexing procedure graphically taking DTLS 1.3
and earlier versions of DTLS into account.
Draft: draft-ietf-tls-dtls13

Commentary: In both versions of DTLS we have to do the extension negotiation because you have to agree on the CID values . In both versions we have to carry the CID in the record layer ( if the CID is used ) . The way we incorporated the CID into the headers is different between the different versions . In DTLS 1.3 we have this variable length header and in DTLS 1.2 we do n't . There are also privacy differences . 
 I 'm inclined not to add anything here . If you feel strongly maybe you could provide a PR ? 
 I think the privacy differences ( and ability to change values over the lifetime of an association , e.g. , when roaming ) are probably worth mentioning . do you plan to write some text ? If not I can try to squeeze it in . 
 PR is available at 
 Fixed in . Closing . 
 LGTM
Paragraph (version A):
The three high bits of the first byte of the DTLSCiphertext header
are set to 001.  This ensures that the value will fit within the
DTLS region when multiplexing is performed as described in
RFC7983.  It also ensures that distinguishing encrypted DTLS 1.3
records from encrypted DTLS 1.2 records is possible when they are
carried on the same host/port quartet; such multiplexing is only
possible when connection IDs I-D.ietf-tls-dtls-connection-id are
in use, in which case DTLS 1.2 records will have the content type
tls12_cid (25).
Paragraph (version B):
The three high bits of the first byte of the DTLSCiphertext header
are set to 001.  This ensures that the value will fit within the
DTLS region when multiplexing is performed as described in
RFC7983.  It also ensures that distinguishing encrypted DTLS 1.3
records from encrypted DTLS 1.2 records is possible when they are
carried on the same host/port quartet; such multiplexing is only
possible when CIDs I-D.ietf-tls-dtls-connection-id are in use, in
which case DTLS 1.2 records will have the content type tls12_cid
(25).
Paragraph (version B):
In both versions of DTLS extension negotiation is used to agree on
the use of the CID feature and the CID values.  In both versions
the CID is carried in the DTLS record header (if negotiated).
However, the way the CID is included in the record header differs
between the two versions.
Draft: draft-ietf-tls-dtls13

Commentary: … 
 I do n't . 
 It would also be good to add a note on how we tell the difference between DTLS 1.2 and 1.3 . Version information is carried in various places and due to the use of the CID the multiplexing got more complex between 1.2 and 1.3 . 
 This WFM
Paragraph (version A):
The three high bits of the first byte of the DTLSCiphertext header
are set to 001.  This ensures that the value will fit within the
DTLS region when multiplexing is performed as described in
RFC7983.
Paragraph (version B):
The three high bits of the first byte of the DTLSCiphertext header
are set to 001.  This ensures that the value will fit within the
DTLS region when multiplexing is performed as described in
RFC7983.  It also ensures that distinguishing encrypted DTLS 1.3
records from encrypted DTLS 1.2 records is possible when they are
carried on the same host/port quartet; such multiplexing is only
possible when connection IDs I-D.ietf-tls-dtls-connection-id are
in use, in which case DTLS 1.2 records will have the content type
tls12_cid (25).
Draft: draft-ietf-tls-dtls13

Commentary:   wrote Text would not hurt in the draft to explain this . 
  , please opine on whether this should get confirmed on the list .
Paragraph (version A):
The S bit (0x08) indicates the size of the sequence number.  0
means an 8-bit sequence number, 1 means 16-bit.
Paragraph (version B):
The S bit (0x08) indicates the size of the sequence number.  0
means an 8-bit sequence number, 1 means 16-bit.  Implementations
MAY mix sequence numbers of different lengths on the same
connection.
Paragraph (version A):
The length field MAY be omitted by clearing the L bit, which means
that the record consumes the entire rest of the datagram in the lower
level transport.  In this case it is not possible to have multiple
DTLSCiphertext format records without length fields in the same
datagram.  Omitting the length field MUST only be used for the last
record in a datagram.
Paragraph (version B):
The length field MAY be omitted by clearing the L bit, which means
that the record consumes the entire rest of the datagram in the lower
level transport.  In this case it is not possible to have multiple
DTLSCiphertext format records without length fields in the same
datagram.  Omitting the length field MUST only be used for the last
record in a datagram.  Implementations MAY mix records with and
without length fields on the same connection.
Draft: draft-ietf-tls-dtls13

Commentary: It 's possible to negotiate the CID extension but that you want to receive an empty CID ( this is how you get asymmetrical CID lengths ) . The current text says : CID . If an implementation receives these messages when CIDs were not negotiated , it MUST abort the connection with an unexpected_message alert . But does this mean that ( for instance ) you can negotiate receiving an empty CID and then switch to a non - empty ? I am tempted to say " no " as I recall QUIC did . 
 Doing what QUIC did seems prudent ... and if I did n't know what QUIC did I think I would also lean towards disallowing switching between empty and non - empty on a live connection .
Paragraph (version A):
If the client and server have negotiated use of the "connection_id"
extension, either side can request a new CID using the
RequestConnectionId message.  In general, implementations SHOULD use
a new CID whenever sending on a new path, and SHOULD request new CIDs
for this purpose if path changes are anticipated.
Paragraph (version B):
Implementations which either did not negotiate the "connection_id"
extension or which have negotiated receiving an empty CID MUST NOT
send NewConnectionId.  Implementations MUST NOT send
RequestConnectionId when sending an empty connection ID.
Implementations which detect a violation of these rules MUST
terminate the connection with an "unexpected_message" alert.
Paragraph (version B):
Implementations SHOULD use a new CID whenever sending on a new path,
and SHOULD request new CIDs for this purpose if path changes are
anticipated.
Draft: draft-ietf-tls-dtls13

Commentary: ( Probably want to fix the typo for " Fixes " in the PR title , but the content looks good to me ) 
 DTLS 1.3 does not really change this aspect compared to earlier DTLS versions . We could reference a number of the other TLS WG documents that attempt to reduce the size of the certificate message , such as Client Certificate URL Cached Info Certificate Compression Following the guidelines in RFC 7925 Other certificate types It may be possible to use the fragmentation mechanism to send one certificate after the other in the certificate chain . Is this what you had in mind ?
Paragraph (version B):
DTLS does not have any built-in congestion control or rate control;
in general this is not an issue because messages tend to be small.
However, in principle, some messages - especially Certificate - can
be quite large.  If all the messages in a large flight are sent at
once, this can result in network congestion.  A better strategy is to
send out only part of the flight, sending more when messages are
acknowledged.  DTLS offers a number of mechanisms for minimizing the
size of the certificate message, including the cached information
extension RFC7924 and certificate compression RFC8879.
Draft: draft-ietf-tls-dtls13

Commentary: Trying to address 
 could one of you do this ? 
 Added a PR
Paragraph (version A):
Note: While some post-handshake messages follow a request/response
pattern, this does not necessarily imply receipt.  For example, a
KeyUpdate sent in response to a KeyUpdate with update_requested does
not implicitly acknowledge that message because the KeyUpdates might
have crossed in flight.
Paragraph (version B):
Note: While some post-handshake messages follow a request/response
pattern, this does not necessarily imply receipt.  For example, a
KeyUpdate sent in response to a KeyUpdate with request_update set to
'update_requested' does not implicitly acknowledge the earlier
KeyUpdate message because the two KeyUpdate messages might have
crossed in flight.
Paragraph (version A):
As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to
indicate that they are updating their sending keys.  As with other
handshake messages with no built-in response, KeyUpdates MUST be
acknowledged.  In order to facilitate epoch reconstruction
reconstructing implementations MUST NOT send with the new keys or
send a new KeyUpdate until the previous KeyUpdate has been
acknowledged (this avoids having too many epochs in active use).
Paragraph (version B):
As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to
indicate that they are updating their sending keys.  As with other
handshake messages with no built-in response, KeyUpdates MUST be
acknowledged.  In order to facilitate epoch reconstruction
reconstructing implementations MUST NOT send records with the new
keys or send a new KeyUpdate until the previous KeyUpdate has been
acknowledged (this avoids having too many epochs in active use).
Paragraph (version B):
dtls-key-update shows an example exchange illustrating that a
successful ACK processing updates the keys of the KeyUpdate message
sender, which is reflected in the change of epoch values.