jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-tls-dtls-connection-id

Commentary: To address 
 Thanks ! This PR fixes the missing size of the introduced length . 
 I miss the hint for the size of . I would assume it 's a 2 bytes value . Is that right ? Is this information already in the document and have overseen it ? Both introduce a special " length " and use different approaches to do so . One with extra definition , one with a included definition . Is this intended ? 
 Fixed with
Paragraph (version A):
The length (in bytes) of the serialised DTLSInnerPlaintext.  The
length MUST NOT exceed 2^14.
Paragraph (version B):
The length (in bytes) of the serialised DTLSInnerPlaintext.  The
length MUST NOT exceed 2^14.  This field is of type uint16.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: Based on 
 Thanks ! 
  wrote :
Mailing list commentary: LGTM . I would strike " , if these privacy properties are important in a given deployment " from the acknowledgments section ( which is an odd place for the accompanying statement . I would add an explicit note about the lack of CID update making this unsuitable for mobility scenarios . That 's a common use case for this sort of mechanism , but this design lacks any defense against linkability .
Paragraph (version A):
With multi-homing, an adversary is able to correlate the
communication interaction over the two paths, which adds further
privacy concerns.
Paragraph (version B):
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
extension unsuitable for mobility scenarios where correlation must be
considered.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: Alternative approach to PR
Paragraph (version A):
This is effectively the simplest possible design that will work.
Previous design ideas for using cryptographically generated session
ids, either using hash chains or public key encryption, were
dismissed due to their inefficient designs.  Note that a client
always has the chance to fall back to a full handshake or more
precisely to a handshake that uses session resumption.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: Trying to address but also trying to expand the description a bit for clarity . 
 According all records seems to use a . Does this include the ? 
 Does this PR provide an improvement help ? 
 Yes , it clarifies it for me .
Paragraph (version B):
Note that it is not possible to parse the records without knowing how
long the Connection ID is.
Paragraph (version A):
This extension is applicable for use with DTLS 1.2 and below. dtls-
record12 illustrates the record format.  I-D.ietf-tls-dtls13
specifies how to carry the CID in a DTLS 1.3 record.
Paragraph (version A):
Note that for both record formats, it is not possible to parse the
records without knowing how long the Connection ID is.
Paragraph (version B):
This specification defines the DTLS 1.2 record layer format and I-
D.ietf-tls-dtls13 specifies how to carry the CID in DTLS 1.3.
Paragraph (version A):
When CID is being used, the DTLSCompressed value is first wrapped
along with the true content type and padding into a
DTLSWrappedCompressed value prior to encryption.  The
DTLSWrappedCompressed value is then encrypted.
Paragraph (version A):
The true content type.
Paragraph (version A):
Padding, as defined in RFC8446.
Paragraph (version B):
When CID is being used, the content to be sent is first wrapped along
with the true content type and padding into a DTLSInnerPlaintext
value prior to encryption.  The DTLSInnerPlaintext value is then
encrypted. dtls-record12 illustrates the record format.
Paragraph (version B):
This field contains the byte encoding of a handshake, an alert
message, or the raw bytes of the application's data to send.
Paragraph (version B):
The DTLSInnerPlaintext.type value contains the content type of the
record.  This is the non-obfuscated (true) content type.
Paragraph (version B):
The outer opaque_type field of a DTLSCiphertext record is always
set to the value 25 (tls12_cid).  The actual content type of the
record is found in DTLSInnerPlaintext.type after decryption.  By
encapsulating the true content type inside the encrypted payload
the outer content type (special_type) can be used to signal the
new record layer format containing the CID.
Paragraph (version B):
The DTLSCiphertext.version field describes the protocol being
employed.  This document describes an extension to DTLS version
1.2.
Paragraph (version B):
The DTLSCiphertext.length field indicates the length (in bytes) of
the following DTLSCiphertext.encrypted_record, which is the sum of
the lengths of the content and the padding, plus one for the inner
content type, plus any expansion added by the AEAD algorithm.
Paragraph (version B):
The AEAD-encrypted form of the serialized DTLSInnerPlaintext
structure.
Paragraph (version B):
Other fields are defined in RFC 6347.  Note that this specification
does not make use of the DTLSCompressed structure.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: This is pretty trivial , but the first use of CID in the draft is n't mated to the expanded " connection ID " . Probably more seriously , that first mention is actually to cite a struct : The structure is called .
Paragraph (version A):
This document defines an extension to DTLS to add a connection ID to
the DTLS record layer.  The presence of the connection ID is
negotiated via a DTLS extension.
Paragraph (version B):
This document defines an extension to DTLS to add a connection ID
(CID) to the DTLS record layer.  The presence of the connection ID is
negotiated via a DTLS extension.
Paragraph (version A):
The extension_data field of this extension, when included in the
ClientHello, MUST contain the CID structure, which carries the CID
which the client wishes the server to use when sending messages
towards it.  A zero-length value indicates that the client is
prepared to send with a connection ID but does not wish the server to
use one when sending (alternately, this can be interpreted as the
client wishes the server to use a zero-length CID; the result is the
same).
Paragraph (version B):
The extension_data field of this extension, when included in the
ClientHello, MUST contain the ConnectionId structure, which carries
the CID which the client wishes the server to use when sending
messages towards it.  A zero-length value indicates that the client
is prepared to send with a connection ID but does not wish the server
to use one when sending (alternately, this can be interpreted as the
client wishes the server to use a zero-length CID; the result is the
same).
Paragraph (version A):
With multi-homing, an adversary is able to correlate the
communication interaction over the two paths, which adds further
privacy concerns.  In order to prevent this, implementations SHOULD
attempt to use fresh connection IDs whenever they change local
addresses or ports (though this is not always possible to detect).
Paragraph (version B):
With multi-homing, an adversary is able to correlate the
communication interaction over the two paths, which adds further
privacy concerns.
Draft: draft-ietf-tls-dtls-connection-id

Commentary: discussed in YUL . 
 Still contains the content types removed in PR . alertwithcid(25 ) handshakewithcid(26 ) applicationdatawithcid(27 ) heartbeatwithcid(28 ) I guess , it should be updated towards PR ? tls12cid(25 ) 
 The PR can be found here : 
 The PR will fix it . 
 If you subscribe to the theory that DTLS has to mux with the realtime protocols , this takes a good slice of the remaining codepoints space . Though TLS has between 20 and 63 , DTLS 1.3 takes 32 - 63 and the registration of 4 more would leave just 3 : 29 , 30 , and 31 . I submit that we might be better considering the TLS 1.3 record construction with a single codepoint . That would get us content type encryption and arbitrary padding as a secondary benefit . All for the modest cost of one octet . 
 If DTLS 1.3 used a demux prefix scheme like the one proposed , this should be no longer an issue . 
 Addressed in
Paragraph (version B):
The true content type is inside the encryption envelope, as
described below.
Paragraph (version B):
When CID is being used, the DTLSCompressed value is first wrapped
along with the true content type and padding into a
DTLSWrappedCompressed value prior to encryption.  The
DTLSWrappedCompressed value is then encrypted.
Paragraph (version B):
The true content type.
Paragraph (version B):
Padding, as defined in RFC8446.