jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-perc-private-media-framework

Commentary: Changed reference to Tunnel and an ( interim ) reference to  's PERC signaling draft 
 Added the actual reference to ietf - roach - perc - webrtc in the body . 
 LGTM
Paragraph (version A):
An endpoint's ability to join a conference hosted by a Media
Distributor MUST NOT alone be interpreted as being authorized to have
access to the E2E media encryption keys, as the Media Distributor
does not have the ability to determine whether an endpoint is
authorized.  Trusted endpoint authorization is described in the (add
ref to new signaling draft here).
Paragraph (version B):
An endpoint's ability to join a conference hosted by a Media
Distributor MUST NOT alone be interpreted as being authorized to have
access to the E2E media encryption keys, as the Media Distributor
does not have the ability to determine whether an endpoint is
authorized.  Trusted endpoint authorization is described in WebRTC
Signaling for PERC I-D.ietf-roach-perc-webrtc.
Paragraph (version A):
To facilitate key exchange required to establish or generate an E2E
key and a HBH key for an endpoint and the same HBH key for the Media
Distributor, this framework utilizes a DTLS-SRTP RFC5764 association
between an endpoint and the Key Distributor.  To establish this
association, an endpoint will send DTLS-SRTP messages to the Media
Distributor which will then forward them to the Key Distributor as
defined in I-D.jones-perc-dtls-tunnel.  The Key Encryption Key (KEK)
(i.e., EKTKey) is also conveyed by the Key Distributor over the DTLS
association to endpoints via procedures defined in PERC EKT [I-
D.ietf-perc-srtp-ekt-diet].
Paragraph (version B):
To facilitate key exchange required to establish or generate an E2E
key and a HBH key for an endpoint and the same HBH key for the Media
Distributor, this framework utilizes a DTLS-SRTP RFC5764 association
between an endpoint and the Key Distributor.  To establish this
association, an endpoint will send DTLS-SRTP messages to the Media
Distributor which will then forward them to the Key Distributor as
defined in I-D.draft-ietf-perc-dtls-tunnel.  The Key Encryption Key
(KEK) (i.e., EKTKey) is also conveyed by the Key Distributor over the
DTLS association to endpoints via procedures defined in PERC EKT [I-
D.ietf-perc-srtp-ekt-diet].
Paragraph (version A):
The Key Distributor needs to know what endpoints are being added to a
given conference.  Thus, the Key Distributor and the Media
Distributor will need to know endpoint-to-conference mappings, which
is enabled by exchanging a conference-specific unique identifier as
defined in I-D.jones-perc-dtls-tunnel.  How this unique identifier is
assigned is outside the scope of this document.
Paragraph (version B):
The Key Distributor needs to know what endpoints are being added to a
given conference.  Thus, the Key Distributor and the Media
Distributor will need to know endpoint-to-conference mappings, which
is enabled by exchanging a conference-specific unique identifier as
defined in I-D.draft-ietf-perc-dtls-tunnel.  How this unique
identifier is assigned is outside the scope of this document.
Draft: draft-ietf-perc-srtp-ekt-diet

Commentary: Does this way of phrasing it look better ? 
 2 )  , : I got ta ask why the MessageType byte is n’t first ? Would n’t putting the MessageType first allow you avoid buffering everything before proceeding ? It seems like you ’re counting on nobody sending a string of zeros as the first byte of the EKT field to mess with implementations .
Paragraph (version A):
The final byte is checked to determine which EKT format is in use.
When an SRTP or SRTCP packet contains a ShortEKTField, the
ShortEKTField is removed from the packet then normal SRTP or SRTCP
processing occurs.  If the packet contains a FullEKTField, then
processing continues as described below.
Paragraph (version B):
The final byte is checked to determine which EKT format is in use.
When an SRTP or SRTCP packet contains a ShortEKTField, the
ShortEKTField is removed from the packet then normal SRTP or SRTCP
processing occurs.  If the packet contains a FullEKTField, then
processing continues as described below.  The reason for using the
last byte of the packet to indicate the type is that the length of
the SRTP or SRTCP part is not known until the decryption has
occurred.  At this point in the processing, there is no easy way
to know where the EKT field would start.  However, the whole UDP
packet has been received so instead of the starting at the front
of the packet, the parsing works backwards off the end of the
packet and thus the type is put at the very end of the packet.
Draft: draft-ietf-perc-srtp-ekt-diet

Commentary: If anyone has ideas on how to write this is a more clear way , love any suggestions ... 
 s2.1 , MessageType Maybe it ’s late but I ’m having trouble parsing this sentence : Values less than 64 are mandatory to understand and the whole EKTField SHOULD be discarded if it contains message type value that is less than 64 and is not implemented . Can “ and is not implemented ” be dropped ?
Paragraph (version A):
The last byte is used to indicate the type of the EKTField.  This
MUST be 2 in the FullEKTField format and 0 in ShortEKTField
format.  Values less than 64 are mandatory to understand and the
whole EKTField SHOULD be discarded if it contains message type
value that is less than 64 and is not implemented.
Paragraph (version B):
The last byte is used to indicate the type of the EKTField.  This
MUST be 2 in the FullEKTField format and 0 in ShortEKTField
format.  Values less than 64 are mandatory to understand while
other values are optional to understand.  A receiver SHOULD
discard the whole EKTField if it contains any message type value
that is less than 64 and that is not understood.  Message type
values that are 64 or greater but not implemented or understood
can simply be ignored.
Draft: draft-ietf-perc-private-media-framework

Commentary: Fixed typos / deleted extra words in the Conf I d section . 
 LGTMlooks good .
Paragraph (version A):
The Key Distributor needs to know what endpoints are to being added
to in a given conference resource.  Thus, the Key Distributor and the
Media Distributor will need to know endpoint-to-conference mappings,
which is enabled by exchanging a conference-specific unique
identifier as defined in I-D.jones-perc-dtls-tunnel.  How this unique
identifier is assigned is outside the scope of this document.
Paragraph (version B):
The Key Distributor needs to know what endpoints are being added to a
given conference.  Thus, the Key Distributor and the Media
Distributor will need to know endpoint-to-conference mappings, which
is enabled by exchanging a conference-specific unique identifier as
defined in I-D.jones-perc-dtls-tunnel.  How this unique identifier is
assigned is outside the scope of this document.
Draft: draft-ietf-perc-double

Commentary: Tried to fix a few minor wording issues which I found when reading this document .
Paragraph (version A):
If a Media Distributor modifies an original RTP header value, the
Media Distributor MUST include the OHB extension to reflect the
changed value, setting the X bit in the RTP header to 1 if no header
extensions were originally present.  If another Media Distributor
along the media path makes additional changes to the RTP header and
any original value is not already present in the OHB, the Media
Distributor must extend the OHB by adding the changed value to the
OHB.  To properly preserve original RTP header values, a Media
Distributor MUST NOT change a value already present in the OHB
extension.
Paragraph (version B):
If a Media Distributor modifies an original RTP header value, the
Media Distributor MUST include the OHB extension to reflect the
changed value, setting the X bit in the RTP header to 1 if no header
extensions were originally present.  If another Media Distributor
along the media path makes additional changes to the RTP header and
any original value is already present in the OHB, the Media
Distributor must extend the OHB by adding the changed value to the
OHB.  To properly preserve original RTP header values, a Media
Distributor MUST NOT change a value already present in the OHB
extension.
Paragraph (version A):
The receiver can check the authentication of the initial and extra
envelope information.  This, along with the OBH, i used to construct
a synthetic packet that is should be identital to one the sender
created and the receiver can check that it is identical and then
decrypt the original payload.
Paragraph (version B):
The receiver can check the authentication of the initial and extra
envelope information.  This, along with the OBH, is used to construct
a synthetic packet that is should be identital to one the sender
created and the receiver can check that it is identical and then
decrypt the original payload.
Paragraph (version A):
It is obviously critical that the intermediary have only the outer
transform parameters and not the inner transform parameters.  We rely
on an external key management protocol to assure this property.
Paragraph (version B):
It is obviously critical that the intermediary has only the outer
transform parameters and not the inner transform parameters.  We rely
on an external key management protocol to assure this property.
Draft: draft-ietf-perc-double

Commentary: 2 )  , : I got ta ask why the MessageType byte is n’t first ? Would n’t putting the MessageType first allow you avoid buffering everything before proceeding ? It seems like you ’re counting on nobody sending a string of zeros as the first byte of the EKT field to mess with implementations .
Paragraph (version A):
If an MDD modifies an original RTP header value, the MDD MUST include
the OHB extension to reflect the changed value.  If another MDD along
the media path makes additional changes to the RTP header and any
original value is not already present in the OHB, the MDD must extend
the OHB by adding the changed value to the OHB.  To properly preserve
original RTP header values, an MDD MUST NOT change a value already
present in the OHB extension.
Paragraph (version B):
Note that "R" indicates a reserved bit that MUST be set to zero when
sending a packet and ignored upon receipt.
Paragraph (version B):
If an MDD modifies an original RTP header value, the MDD MUST include
the OHB extension to reflect the changed value, setting the X bit in
the RTP header to 1 if no header extensions were originally present.
If another MDD along the media path makes additional changes to the
RTP header and any original value is not already present in the OHB,
the MDD must extend the OHB by adding the changed value to the OHB.
To properly preserve original RTP header values, an MDD MUST NOT
change a value already present in the OHB extension.