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

Commentary: See for details . 
 Looks good . It 's probably good to also add a note , asking the RFC Editor to replace XXX with the Trickle RFC number , once published . Something like : [ RFC EDITOR NOTE : Please replace RFC XXXX with the RFC number of < xref target="I - D.ietf - ice - trickle"once it has been published . ]
Trickle ICE I-D.ietf-ice-trickle considers a similar problem, namely
whether an ICE agent should allow a checklist to enter the Failed
state if more candidates might still be provided by the remote peer.
The solution, specified in I-D.ietf-ice-trickle, Section 8, is to
wait until an end-of-candidates indication has been received before
determining ICE failure.
However, for the same reasons described above, the ICE agent may
discover peer-reflexive candidates after it has received the end-of-
candidates indication, and so the solution proposed by this document
MUST still be used even when the ICE agent is using Trickle ICE.
Note also that sending an end-of-candidates indication is only a
SHOULD-strength requirement, which means that ICE agents will need to
implement an backup mechanism to decide when all candidates have been
received, typically a timer.  Accordingly, ICE agents MAY use the PAC
timer to also serve as an end-of-candidates fallback.
Draft: draft-ietf-ice-pac

Commentary: It 's a lot of words , makes the sentence harder to read , and given that this is introductory text , does n't really clarify the document . I also think we 'd have to similarly rewrite several other paragraphs in the intro if we did this , so I 'm not in favor of adding the suggested text . 
 Perhaps , there are a few places that talks about " all pairs " , without clarifying that it is for a checklist . So , at the moment , one could read the Introduction saying that ICE failure is typically declared once all pairs associated with the whole session have failed , which is not true . I assume you agree with that ? As you have indicated yourself , ICE failure can be declared when all pairs associated with ONE checklist have failed , even if there are other checklists in the Completed state . Anyway , I think my issue is clarified in the " Update to RFC8445 " section , so in order to move the draft forward , I am willing to accept ( ) and then leave the Introduction text as it is . I guess one has to assume that the reader of the draft knows ICE well enough to understand when ICE failure etc takes place . 
 Right , this is non - normative text , so I think we can keep it simple here and be specific ( as we already have done ) in the 8445 update section .
When using ICE, endpoints will typically exchange ICE candidates,
form a list of candidate pairs, and then test each candidate pair to
see if connectivity can be established.  If the test for a given pair
fails, it is marked accordingly, and if all pairs have failed, the
overall ICE process is considered to have failed.
When using ICE, endpoints will typically exchange ICE candidates,
form a list of candidate pairs, and then test each candidate pair to
see if connectivity can be established.  If the test for a given pair
fails, it is marked accordingly, and if all pairs have failed, the
overall ICE process typically is considered to have failed.
Draft: draft-ietf-ice-pac

Commentary: I committed the change . 
 WHERE : All Candidates Discarded WHAT : Remove / rewrite the following : " ( e.g. , a candidate that contains a FQDN that fails to resolve ) . " WHY : It is unclear whether how / if FQDNs can be used in candidates . I think the text saying that the candidate can not be used for some other reason is enough . 
 Implemented in One issue , though : The text says : " One consequence of this behavior is that in cases where ICE should fail , e.g. , where both sides provide candidates with unsupported address families ICE will no longer fail immediately , and only fail when the aforementioned timer expires . " ( ' unsupported address families ' used to be ' unresolvable FQDNs ' , but the issue is the same ) Q : If both endpoints provide candidates that ca n't be used , how is the timer going to help ? No endpoint will send any connectivity checks , so there will be no peer - reflexive candidates . 
 LG with one minor text change
Even if the ICE agent provides candidates, they may be discarded by
the peer agent if it does not know what to do with them.  For
example, candidates may use an address family that the peer agent
does not support, (e.g., a host candidate with an IPv6 address in a
NAT64 scenario), or may not be usable for some other reason (e.g., a
candidate that contains a FQDN that fails to resolve).
Even if the ICE agent provides candidates, they may be discarded by
the peer agent if it does not know what to do with them.  For
example, candidates may use an address family that the peer agent
does not support, (e.g., a host candidate with an IPv6 address in a
NAT64 scenario), or may not be usable for some other reason.
One consequence of this behavior is that in cases where ICE should
fail, e.g., where both sides provide candidates with unresolvable
FQDNs ICE will no longer fail immediately, and only fail when the
aforementioned timer expires.  However, because most ICE scenarios
require an extended period of time to determine failure, the fact
that some specific scenarios no longer fail fast should have minimal
application impact, if any.
One consequence of this behavior is that in cases where ICE should
fail, e.g., where both sides provide candidates with unsupported
address families, ICE will no longer fail immediately, and only fail
when the aforementioned timer expires.  However, because most ICE
scenarios require an extended period of time to determine failure,
the fact that some specific scenarios no longer fail fast should have
minimal application impact, if any.
Draft: draft-ietf-ice-pac

Commentary: I committed both changes . 
 WHERE : Update to RFC 8445 WHAT : Modify ... " ; note that receipt of an ICE candidate is not required . " that it also indicates that no candidate needs to be SENT before the timer is started . WHY : The text in unclear on whether a candidate needs to be sent or not before the timer is started . The text only says that a candidate does not need to be received . 
 ok 
 Implemented in 
 LG with two minor wording changes
Specifically, the ICE agent will start its timer once it believes ICE
connectivity checks are starting.  This occurs when the agent has
sent the values needed to perform connectivity checks (e.g., the
Username Fragment and Password denoted in RFC8445, Section 5.3) and
has received some indication that the remote side is ready to start
connectivity checks, typically via receipt of the values mentioned
above; note that receipt of an ICE candidate is not required.
Specifically, the ICE agent will start its timer once it believes ICE
connectivity checks are starting.  This occurs when the agent has
sent the values needed to perform connectivity checks (e.g., the
Username Fragment and Password denoted in RFC8445, Section 5.3) and
has received some indication that the remote side is ready to start
connectivity checks, typically via receipt of the values mentioned
above.  Note that the agent will start the timer even if it has not
sent or received any ICE candidates.
Draft: draft-ietf-ice-pac

Commentary: Ok . 
 Looks good . 
 Where : Introduction What : s / candidate addresses / ICE candidates Why : An address is just one part of a candidate 
 I tend to think this is implicit , and wo n't confuse anyone . 
 We use " candidates " everywhere else , and it is not only the addresses that are exchanged . 
 8445 also uses ' candidate transport addresses ' in Section 2 . But open to some other text here , ' ICE candidates ' feels like it does n't explain enough to the reader . 
 The paragraph says : " Typically , when using ICE , endpoints will exchange candidate addresses , form a list of candidate pairs , and then test each candidate pair to see if connectivity can be established . If the test for a given pair fails , it is marked accordingly , and if all pairs have failed , the overall ICE process is considered to have failed . " If people do n't understand what an " ICE candidate " is they wo n't understand the rest of the text either :) My point is that endpoints are exchanging candidates . The candidate transport addresses are then used for sending connectivity checks . So , if you want to include it , perhaps something like : " and then test each candidate pair , by sending connectivity checks using the candidate transport addresses , to see if .... " 
 Implemented in 
 Reworded , PTAL .
Typically, when using ICE, endpoints will exchange candidate
addresses, form a list of candidate pairs, and then test each
candidate pair to see if connectivity can be established.  If the
test for a given pair fails, it is marked accordingly, and if all
pairs have failed, the overall ICE process is considered to have
failed.
When using ICE, endpoints will typically exchange ICE candidates,
form a list of candidate pairs, and then test each candidate pair to
see if connectivity can be established.  If the test for a given pair
fails, it is marked accordingly, and if all pairs have failed, the
overall ICE process is considered to have failed.
Draft: draft-ietf-ice-pac

Commentary: LGTM with the tweak I 
 Where : Abstract What : s / peer - to - peer connection / connectivity Why : We talk about establishing connectivity elsewhere 
 peer - to - peer seems important to retain here , not sure I agree with this change 
 Then we could at least use " peer - to - peer connectivity " , because that seems to be used once in the Introduction of 8445 . 
 I can get behind that . 
 Something happened . I forked the ICE WG repo , but when I created the PR it ended up in my private repo . 
 You used the wrong repo for the base repo . I fixed it in 
 I think I understand why that happened , ice - wg still thinks cdh4u is upstream , need to think about how to fix that . 
 Should n't it be possible to create a pull request to a fork ? I guess my repo is n't needed anymore , so in worse case we can just remove it . 
 Fixed in 
 Looks good .
During the process of creating a peer-to-peer connection, ICE agents
can encounter situations where they have no candidate pairs to check,
and, as a result, conclude that ICE processing has failed.  However,
because additional candidate pairs can be discovered during ICE
processing, declaring failure at this point may be premature.  This
document discusses when these situations can occur and proposes a way
to avoid premature failure.
During the process of establishing peer-to-peer connectivity, ICE
agents can encounter situations where they have no candidate pairs to
check, and, as a result, conclude that ICE processing has failed.
However, because additional candidate pairs can be discovered during
ICE processing, declaring failure at this point may be premature.
This document discusses when these situations can occur and proposes
a way to avoid premature failure.