jiebi/TextFlow huggingface dataset:
Original text:
<del> An unsigned value implementing the DetNet sequence number. </del>  A separate sequence number space MUST be maintained by the node that adds the d-CW for each DetNet app-flow.  The following sequence

Reviewer comments:
IESG review comment resolutions in this version: DONE Sabrina Tanamal, IANA, (03-12), OK Michael Tüxen, (03-15), Ready with Issues: Seq.Num.Space Shwetha Bhandari, (03-13), Ready TO BE DISCUSSED: Security section Watson Ladd, SecDir, (03-11), Not Ready Uri Blumenthal, (03-13), Security Deborah, (04-09), decrease authors to 6 !!!
reviewed in April 22 meeting

Revised text:
 <ins> An unsigned value implementing the DetNet sequence number.  The sequence number space is a circular one. </ins> A separate sequence number space MUST be maintained by the node that adds the d-CW for each DetNet app-flow.  The following sequence
Original text:
document signing. Term of "Document Sign" in this document is digitally sign contents <del> that are consumed by humans.  To be more precise, contents are intended to be shown to human with printable or displayable form by </del>  means of services or software, rather than processed by machines. 3.1.

Reviewer comments:
there was two more remaining human.
on the section 4, it seems better to change some of "EKU" to "KeyPurposeId" or "EKU values" to highlight following. excluded EKUs procedures checks, whether EKU values contain some OID(KeyPurpiseId), or absence of EKU extension. permitted EKU procedures check, whether EKU values contain some OID(KeyPurposeId).
Current expression on "Excluded EKUs procedure " and "Permitted EKU procedure" seems unclear about whether that procedure prohibits or allows, existence of certain key purpose identifier in the extended key usage value (partial match), OR certain set of key purpose identifier is on key usage value(exact match). my intension was the former. I will review, and will fix that expression if it were unclear. In addition, I will add "restrictions set is derived and implemented from (or configured with) the policy to which the implementation conforms." to clarify policy handling by RP or implementer.

Revised text:
document signing. Term of "Document Sign" in this document is digitally sign contents  <ins> that are consumed by people.  To be more precise, contents are intended to be shown to person with printable or displayable form by </ins> means of services or software, rather than processed by machines. 3.1.
Original text:
signing contents that are consumed by people.  To be more precise, contents are intended to be shown to a person with printable or displayable form by means of services or software, rather than <del> processed by machines. </del>  3.1. This procedure is intended to permit or prohibit presence of a certain KeyPurposeId or complete absence of KeyPurposeIds.  It is outside the scope of this document, but the relying party can <del> permit or prohibit combinations of KeyPurposeIds, instead of </del>  single KeyPurposeId.  A consideration on prohibiting combinations of KeyPurposeIds is described in the Security Considerations section of this document.  If both "Excluded KeyPurposeId" and

Reviewer comments:
Addressing Erik's . Given that documents may be presented to people "by means of ... software" perhaps a slight tweak to the "rather than processed by machines", e.g.: "rather than processed primarily by machines", or "rather than processed principally by machines" s/instead of single/instead of a single/ s/proresses/processes/ I think?

Revised text:
signing contents that are consumed by people.  To be more precise, contents are intended to be shown to a person with printable or displayable form by means of services or software, rather than  <ins> primarily processed by machines. </ins> 3.1. This procedure is intended to permit or prohibit presence of a certain KeyPurposeId or complete absence of KeyPurposeIds.  It is outside the scope of this document, but the relying party can  <ins> permit or prohibit combinations of KeyPurposeIds, instead of a </ins> single KeyPurposeId.  A consideration on prohibiting combinations of KeyPurposeIds is described in the Security Considerations section of this document.  If both "Excluded KeyPurposeId" and
Original text:
Abstract <del> 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. </del>  1.

Reviewer comments:
LGTM with the tweak I added
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 URL
I think I understand why that happened, ice-wg still thinks cdh4u is upstream, need to think about how to fix that.
Shouldn't it be possible to create a pull request to a fork? I guess my repo isn't needed anymore, so in worse case we can just remove it.
Fixed in
Looks good.

Revised text:
Abstract  <ins> 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. </ins> 1.
Original text:
(ICE), for Network Address Translator (NAT) traversal for UDP-based communication. <del> 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. </del>  During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote

Reviewer comments:
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 won'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 doesn'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 don't understand what an "ICE candidate" is they won'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.

Revised text:
(ICE), for Network Address Translator (NAT) traversal for UDP-based communication.  <ins> 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. </ins> During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote
Original text:
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 <del> above; note that receipt of an ICE candidate is not required. </del>  The RECOMMENDED duration for the timer is equal to the agent's connectivity check transaction timeout, including all

Reviewer comments:
I committed both changes.
WHERE: Update to RFC 8445 WHAT: Modify... "; note that receipt of an ICE candidate is not required." URL 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

Revised text:
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  <ins> above.  Note that the agent will start the timer even if it has not sent or received any ICE candidates. </ins> The RECOMMENDED duration for the timer is equal to the agent's connectivity check transaction timeout, including all
Original text:
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 <del> NAT64 scenario), or may not be usable for some other reason (e.g., a candidate that contains a FQDN that fails to resolve). </del>  In these scenarios, when the candidates are discarded, the checklist at the peer agent will once again be empty, leading to immediate ICE there are no such checklists, no action is necessary. One consequence of this behavior is that in cases where ICE should <del> 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. </del>  Note also that the timer is potentially relevant to the ICE nomination procedure described in RFC8445, Section 8.1.1.  That

Reviewer comments:
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 cannot 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 can'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

Revised text:
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  <ins> NAT64 scenario), or may not be usable for some other reason. </ins> In these scenarios, when the candidates are discarded, the checklist at the peer agent will once again be empty, leading to immediate ICE there are no such checklists, no action is necessary. One consequence of this behavior is that in cases where ICE should  <ins> 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. </ins> Note also that the timer is potentially relevant to the ICE nomination procedure described in RFC8445, Section 8.1.1.  That
Original text:
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 <del> overall ICE process is considered to have failed. </del>  During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote

Reviewer comments:
It's a lot of words, makes the sentence harder to read, and given that this is introductory text, doesn'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.

Revised text:
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  <ins> overall ICE process typically is considered to have failed. </ins> During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote
Original text:
5.  The security considerations for ICE are defined in RFC8445.  This specification only recommends that ICE agents wait for a certain time of period before they declare ICE failure, and does not introduce new security considerations. <del> 6. </del>  This specification makes no requests to IANA.

Reviewer comments:
See URL 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 once it has been published.]

Revised text:
5. <ins> [RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of draft-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. 6. </ins> The security considerations for ICE are defined in RFC8445.  This specification only recommends that ICE agents wait for a certain time of period before they declare ICE failure, and does not introduce new security considerations.  <ins> 7. </ins> This specification makes no requests to IANA.
Original text:
RFC4291, whose identity cannot be safely confirmed using TLS certificates under most conditions. <del> Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver presented in the certificate.  Opportunistic Privacy similarly applies to DoQ RFC9250.  A client MAY use information from the SVCB record for "resolver.arpa" with this "opportunistic" approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted DNS Resolver does not differ from the IP address of the Unencrypted DNS Resolver.  Clients SHOULD use this mode only for resolvers using private or local IP addresses, since resolvers that use other addresses are able to provision TLS certificates for their addresses. </del>  5.

Reviewer comments:
…tion
Section 4.2, verified, calls out the entire cert check for validation, but section 4.3, opportunistic, only talks about skipping the IP validation. It has gone without saying that these are equivalent because the IP is the only thing about the cert being validated, but for implementors, does this mean they can skip the entire cert validation process (meaning the connection will be used even if other errors occur, such as the cert being expired)? I assume yes (no cert checking of any kind), but we should be specific.
I think it's up to implementations. If I look at the opportunistic profile in RFC 7858, it say: I think we should point to that and explain that it's open to the client to determine how opportunistic it wants to be
LGTM

Revised text:
RFC4291, whose identity cannot be safely confirmed using TLS certificates under most conditions.  <ins> An Opportunistic Privacy Profile is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver presented in the certificate.  This Opportunistic Privacy Profile similarly applies to DoQ RFC9250.  For this profile, Section 4.1 of RFC7858 explains that clients might or might not validate the resolver; however, even if clients choose to perform some certificate validation checks, they will not be able to validate the names presented in the SubjectAlternativeName field of the certificate for private and local IP addresses. A client MAY use information from the SVCB record for "resolver.arpa" with this Opportunistic Privacy Profile as long as the IP address of the Encrypted DNS Resolver does not differ from the IP address of the Unencrypted DNS Resolver.  Clients SHOULD use this mode only for resolvers using private or local IP addresses, since resolvers that use other addresses are able to provision TLS certificates for their addresses. </ins> 5.
Original text:
connections, or in the URI host for DoH requests. When performing discovery using resolver IP addresses, clients MUST <del> use the IP address as the URI host for DoH requests. </del>  Note that since IP addresses are not supported by default in the TLS SNI, resolvers that support discovery using IP addresses will need to

Reviewer comments:
In 6.3 we say: "When performing discovery using resolver IP addresses, clients MUST use the IP address as the URI host for DoH requests." There are multiple IP addresses that may be in-play here. We should clarify which is "the IP address" in the case where the Designated Resolver and the Unencrypted Resolver do NOT share an IP. (I take it that this is the IP of the Unencrypted Resolver ?)
Good point!
LGTM

Revised text:
connections, or in the URI host for DoH requests. When performing discovery using resolver IP addresses, clients MUST  <ins> use the original IP address of the Unencrypted DNS Resolver as the URI host for DoH requests. </ins> Note that since IP addresses are not supported by default in the TLS SNI, resolvers that support discovery using IP addresses will need to
Original text:
(RA) options RFC8106, as well as manual configuration. This document defines two mechanisms for clients to discover <del> designated resolvers using DNS server Service Binding (SVCB, I- D.ietf-dnsop-svcb-https) records: </del>  When only an IP address of an Unencrypted DNS Resolver is known, the client queries a special use domain name (SUDN) RFC6761 to

Reviewer comments:
From Section 1 Introduction, it is not obvious if the two mechanisms mentioned in the section are alternative or complementary, and how they relate to the DoT, DoQ and DoH requirements introduced in the same section. Section 4 gets into details about DoT and DoQ using IP addresses - it would be good to explain a little more about it in the Intro section. In Section 5, the requirements seem to overlap with draft-ietf-add-svcb-dns. It would be good to further clarify the relationship between the two specifications. Finally, since multiple solutions are presented, some recommendations about when, how and why one mechanism should be used vs the other would be useful to the reader.
LGTM

Revised text:
(RA) options RFC8106, as well as manual configuration. This document defines two mechanisms for clients to discover  <ins> designated resolvers that support these encrypted protocols using DNS server Service Binding (SVCB, I-D.ietf-dnsop-svcb-https) records: </ins> When only an IP address of an Unencrypted DNS Resolver is known, the client queries a special use domain name (SUDN) RFC6761 to