jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-ice-rfc5245bis

Commentary: Looks good !
If the using protocol is using the ICE mismatch feature, a way is
needed to convey this parameter in answers.  It is a boolean flag.
The exchange of parameters is symmetric; both agents need to send the
same set of attributes as defined above.
If the using protocol is vulnerable to, and able to detect, ICE
mismatch (sec-verify), a way is needed for the detecting agent to
convey this information to its peer.  It is a boolean flag.
Certain middleboxes, such as ALGs, may alter the ICE candidate
information that breaks ICE.  If the using protocol is vulnerable to
this kind of changes, called ICE mismatch, the responding agent needs
to detect this and signal this back to the initiating agent.  The
details on whether this is needed and how it is done is defined by
the usage specifications.  One exception to the above is that an
initiating agent would never indicate ICE mismatch.
Certain middleboxes, such as ALGs, can alter signaling information
that breaks ICE.  This is referred to as ICE mismatch.  If the using
protocol is vulnerable to ICE mismatch, the responding agent needs to
be able to detect it and inform the peer agent about the ICE
mismatch.
Each using protocol needs to define whether the using protocol is
vulnerable to ICE mismatch, how ICE mismatch is detected, and whether
specific actions need to be taken when ICE mismatch is detected.
The controlling ICE agent MUST include the ICE-CONTROLLED attribute
in a Binding request.  The controlled ICE agent MUST include the ICE-
CONTROLLING attribute in a Binding request.
The controlling ICE agent MUST include the ICE-CONTROLLING attribute
in a Binding request.  The controlled ICE agent MUST include the ICE-
CONTROLLED attribute in a Binding request.
Draft: draft-ietf-ice-rfc5245bis

Commentary: It looks like two references did n't get translated into xml2rfc xref tags when RFC 5245 got imported . 
 LGTM ! Thanks !
STUN connectivity checks between agents are authenticated using the
short-term credential mechanism defined for STUN [RFC5389].  This
mechanism relies on a username and password that are exchanged
through protocol machinery between the client and server.  The
username part of this credential is formed by concatenating a
username fragment from each agent, separated by a colon.  Each agent
also provides a password, used to compute the message integrity for
requests it receives.  The username fragment and password are
exchanged between the peers.  In addition to providing security, the
username provides disambiguation and correlation of checks to media
streams.  See Appendix B.4 for motivation.
STUN connectivity checks between agents are authenticated using the
short-term credential mechanism defined for RFC5389.  This mechanism
relies on a username and password that are exchanged through protocol
machinery between the client and server.  The username part of this
credential is formed by concatenating a username fragment from each
agent, separated by a colon.  Each agent also provides a password,
used to compute the message integrity for requests it receives.  The
username fragment and password are exchanged between the peers.  In
addition to providing security, the username provides disambiguation
and correlation of checks to media streams.  See sec-why-uname for
motivation.
Draft: draft-ietf-ice-rfc5245bis

Commentary: Not sure this is correct . ICE session is something that continues until ufrag / passwords change . The same candidates can be re - used across multiple ICE sessions . 
 I think better definition will be : An ICE session consists of all ICE - related actions starting with the candidate gathering , followed by the interactions ( candidate exchange , connectivity checks , nominations and keep - alives ) between the ICE agents until all the candidates are released or ICE - restart is initiated by ufrag / password change . 
 Roman 's suggestion looks good . 
 I think the current proposed explanation ( one with more details ) is good . Would suggest merging this . 
 My suggestion is to merge , submit a new version , and then continue working on  's issues . 
 Why not just say an ICE session is all ICE activity tied to a candidate exchange with a specific ufrag / pwd ? Every time you do a candidate exchange with a new ufrag / pwd , you have a new ICE session . I do n't think we need to say all the rest .
An ICE session consists of all ICE-related actions starting with
the candidate gathering, followed by the interactions (candidate
exchange, connectivity checks, nominations and keep-alives)
between the ICE agents until all the candidates are released or
ICE-restart is triggered.
Draft: draft-ietf-ice-rfc5245bis

Commentary: Alternate version of PR . Rather than structuring the Ta procedures as : If , do , or ; If , do , or ; ... This PR structures them more like pseudocode , with the ability for multiple steps to be run in the same Ta cycle , reducing some text duplication .
NOTE: When timer Ta fires, and the agent processes a CHECK LIST, if
no check is performed for a pair in the CHECK LIST (based on the
rules below), the agent can immediately select the next CHECK LIST in
the Running state, without waiting for timer Ta to expire again.
If there is no candidate pair in the Waiting state, and if there
are one or more pairs in the Frozen state, for each pair in the
Frozen state the the agent checks the foundation associated with
the pair.  For a given foundation, if there is no pair (in any
CHECK LIST in the CHECK LIST SET) in the Waiting or In-Progress
state, the agent performs a connectivity check on the pair and
puts the pair state to In-Prograss.  If, for the same foundation,
there are one or more pairs in the Waiting or In-Progress state,
(in any CHECK LIST in the CHECK LIST SET) the agent does not
perform a connectivity check on the pair.
If the TRIGGERED CHECK QUEUE associated with the CHECK LIST
contains one or more candidate pairs, the agent removes the top
pair from the queue, performs a connectivity check on that pair,
puts the candidate pair state to In-Progress, and aborts the
subsequent steps.
If there is no candidate pair in the Waiting state, and if there
are one or more pairs in the Frozen state, for each pair in the
Frozen state the agent checks the foundation associated with the
pair.  For a given foundation, if there is no pair (in any CHECK
LIST in the CHECK LIST SET) in the Waiting or In-Progress state,
the agent puts the candidate pair state to Waiting and continues
with the next step.
If there are one or more candidate pairs in the Waiting state, the
agent selects the highest-priority candidate pair (if there are
multiple pairs with the same priority, the pair with the lowest
component ID is selected) in the Waiting state, performs a
connectivity check on that pair, puts the candidate pair par state
to In-Progress, and abort the subsequent steps.
If this step is reached, no check could be performed for the
selected CHECK LIST.  So, without waiting for timer Ta to expire
again, select the next CHECK LIST in the Running state and return
to step #1.  If this happens for every single CHECK LIST in the
Running state, meaning there are no remaining candidate pairs to
perform connectivity checks for, abort these steps.
Draft: draft-ietf-ice-rfc5245bis

Commentary: Clarification of the check list candidate pair states .
A check has not been performed for this pair, and can be performed
as soon as it is the highest-priority Waiting pair on the check
list.
A check for this pair was already done and produced a successful
result.
A check for this pair was already done and failed, either never
producing any response or producing an unrecoverable failure
response.
A check for this pair hasn't been performed, and it can't yet be
performed until some other check succeeds, allowing this pair to
unfreeze and move into the Waiting state.
A check has not been sent for this pair, but can be sent as soon
as the pair is chosen based on the criteria for selecting for
which candidate pair a check is to be sent.
A check has been sent for this pair, and produced a successful
result.
A check has been sent for this pair, and failed (a response to the
check was never received, or a failure response was received).
A check for this pair has not been sent, and it can not be sent
until the pair is unfrozen and moved into the Waiting state.
Draft: draft-ietf-ice-rfc5245bis

Commentary:   also contain some text regarding the rate . E.g. " The definition of a " reasonable " rate is that STUN should not use more bandwidth than the RTP itself will use , once media starts flowing . " I guess we should discuss whether : 1 ) We need to remove / modify that text 2 ) Whether B.1 is the place where we should talk about the global rate limit . 
 I 'll own this issue because I 'm driving discussion on the list around the transport guys ' proposal for " MaxPackets+HTO+pacing " . 
 Hopefully fixed by
ICE agents SHOULD use the default Ta value, 50 ms, but MAY use
another value based on the characteristics of the associated media.
ICE agents MUST NOT use a Ta value smaller than 5 ms.
ICE agents SHOULD use the default Ta value, 50 ms, but MAY use
another value based on the characteristics of the associated media.
Regardless of the Ta value chosen for each ICE agent, the combination
of all transactions from all ICE agents (if a given implementation
runs several concurrent ICE agents) MUST NOT be sent more often than
once every 5ms (as though there were one global Ta value for pacing
all ICE agents).
This mechanism of a global minimum pacing interval of 5ms is not
generally applicable to transport protocols, but is applicable to ICE
based on the following reasoning.
Let MaxBytes be the maximum number of bytes allowed to be
outstanding in the network at start-up, which SHOULD be 14600
bytes per RFC 6928.
Let HTO be the transaction timeout, which SHOULD be 2*RTT if
RTT is known and 500ms otherwise.  This is based on the RTO for
STUN messages from RFC 5389 and the the TCP initial RTO, which
is 1 sec in RFC 6298.
Let MinPacing be the minimum pacing interval between
transactions, which SHOULD be 5ms.
Observe that ICE agents typically do not know the RTT for ICE
transactions (connectivity checks in particular), meaning that HTO
will almost always be 500ms.
Observe that a MinPacing of 5ms and HTO of 500ms gives at most 100
packets/HTO, which for a typical ICE check of less than 120 bytes
means a maximum of 12000 outstanding bytes in the network, which
is less than the maximum expressed by rule 1.
Thus, for ICE, the rule set reduces down to just the MinPacing
rule, which is equivalant to having a global Ta value.
Draft: draft-ietf-ice-rfc5245bis

Commentary: Reference update and fixed too wide artwork
If one or more host candidates corresponding to an IPv6 address
generated using a mechanism that prevents location tracking I-
D.ietf-6man-ipv6-address-generation-privacy are gathered, host
candidates corresponding to IPv6 addresses that do allow location
tracking, that are configured on the same interface, and are part
of the same network prefix MUST NOT be gathered; and host
candidates corresponding to IPv6 link-local addresses MUST NOT be
gathered.
If one or more host candidates corresponding to an IPv6 address
generated using a mechanism that prevents location tracking
RFC7721 are gathered, host candidates corresponding to IPv6
addresses that do allow location tracking, that are configured on
the same interface, and are part of the same network prefix MUST
NOT be gathered; and host candidates corresponding to IPv6 link-
local addresses MUST NOT be gathered.