jiebi/TextFlow huggingface dataset:
Original text:
Full Coverage This property specifies the minimum number of bytes in a received <del> message that need to be covered by a checksum.  A special value of 0 means that a received packet does not need to have a non-zero checksum field.  A receiving endpoint will not forward messages that have less coverage to the application.  The application is responsible for handling any corruption within the non-protected part of the message RFC8085. </del>  8.1.2.

Reviewer comments:
, , , , , .
In 8.1.1 the second sentence is convoluted. Is there a way to restate it without as many nots, nons, an different zeros?
Do you really mean "host" at "(endpoints) SHOULD represent the same host" in section 6, or do you mean something more like service, given that an endpoint may configured with a DNS name?
actually we mean service, good catch.
The "reformatted where necessary" part of the requirement in the last paragraph of 4.1 makes the MUST NOT almost impossible to conform to. I think I understand what the paragraph is trying to say, but the current formulation leaves the reader guessing. I think you are trying to say "Avoid using any of the terms listed as keywords in the protocol numbers registry as any part of a vendor or implementation-specific property name".
The first sentence-paragraph of section 4 is complex. Please break it apart.
has a comment that's too long for the text version
In the text version of the document, the last paragraph before 3.1.3 has some markup (~~~) that has leaked through.
As you can tell, I don't think the documents do what the first sentence of the API summary claims. This document would not lose anything if you deleted the sentence.
Agreed, we can lose this sentence.
Why? Removing this makes no sense to me.
For one, it's redundant - it only repeats what we already say earlier twice.
Ah, I see - so just this one instance..... then go ahead, we don't need to say something twice.

Revised text:
Full Coverage This property specifies the minimum number of bytes in a received  <ins> message that need to be covered by a checksum.  A receiving endpoint will not forward messages that have less coverage to the application. The application is responsible for handling any corruption within the non-protected part of the message RFC8085.  A special value of 0 means that a received packet may also have a zero checksum field. </ins> 8.1.2.
Original text:
system can race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent.  Applications need to ensure that they use security APIs appropriately.  In cases where applications use an interface to provide sensitive keying material, e.g., access to private keys or

Reviewer comments:
In (Arch) section 3.3, you are talking about racing before you've described what it is. At the point where you note that racing should only happen over stacks with identical security properties, note when doing so might introduce privacy issues and what can be done about them.
Describe what you mean by caching and why you might want to isolate sessions earlier.

Revised text:
system can race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. <ins> Whether information from previous racing attempts, or other information cached by the Transport Services implementation about past communications, is used during establishment is under application control.  This allows applications to make tradeoffs between efficiency (through racing) and privacy (via information that might leak from the cache toward an on-path observer).  Some applications have native concepts (e.g. "incognito mode") that align with this functionality. </ins> Applications need to ensure that they use security APIs appropriately.  In cases where applications use an interface to provide sensitive keying material, e.g., access to private keys or
Original text:
application. In general, any protocol or path used for a connection must conform <del> to all three sources of constraints.  A violation of any of the layers should cause a protocol or path to be considered ineligible for use.  For an example of application preferences leading to constraints, an application may prohibit the use of metered network interfaces for a given Connection to avoid user cost.  Similarly, the system policy at a given time may prohibit the use of such a metered network interface from the application's process.  Lastly, the implementation itself may default to disallowing certain network interfaces unless explicitly requested by the application and allowed by the system. </del>  It is expected that the database of system policies and the method of looking up these policies will vary across various platforms.  An

Reviewer comments:
Fix to Issue
We don’t mention layers in the text before: “A violation of any of the layers should cause” Is this better as: ” A violation that occurs at any of the policer layers should cause”
Fixed

Revised text:
application. In general, any protocol or path used for a connection must conform  <ins> to all three sources of constraints.  A violation that occurs at any of the policy layers should cause a protocol or path to be considered ineligible for use.  For an example of application preferences leading to constraints, an application may prohibit the use of metered network interfaces for a given Connection to avoid user cost. Similarly, the system policy at a given time may prohibit the use of such a metered network interface from the application's process. Lastly, the implementation itself may default to disallowing certain network interfaces unless explicitly requested by the application and allowed by the system. </ins> It is expected that the database of system policies and the method of looking up these policies will vary across various platforms.  An
Original text:
certificate directly instead of relying on a referential mechanism such as communicating only a hash and/or URL for the certificate. <del> Any security association protocol MUST use PFS (such as profiles providing PFS). </del>  The degree of security required on every hop of an ACP network needs to be consistent across the network so that there is no designated

Reviewer comments:
During IETF 106 I solicited some feedback on the ACP IPsec/IKEv2 usage from Valery Smyslov; I've tried to digest that feedback into new text here. Some aspects are still subject to change. I also made a minor tweak to the DTLS section to bring it into parity with the IPsec one.
Merging first, then fixing.

Revised text:
certificate directly instead of relying on a referential mechanism such as communicating only a hash and/or URL for the certificate.  <ins> Any security association protocol MUST provide Forward Secrecy (whether inherently or as part of a profile of the security association protocol). </ins> The degree of security required on every hop of an ACP network needs to be consistent across the network so that there is no designated
Original text:
6.7.1. <del> An ACP node announces its ability to support IKEv2 as the ACP secure channel protocol in GRASP as "IKEv2". </del>  6.7.1.1. To run ACP via IPsec natively, no further IANA assignments/ definitions are required. <del> An ACP node that is supporting native IPsec MUST use IPsec security setup via IKEv2 for tunnel mode and IPsec/IKE signaling accordingly for IPv6 payload (e.g.: ESP next header of 41).  It MUST use local and peer link-local IPv6 addresses for encapsulation. Authentication MUST use the ACP domain certificates.  Certificate Encoding MUST support "PKCS #7 wrapped X.509 certificate" (0) (see IKEV2IANA for this and other IANA IKEv2 parameter names used in this text).  If certificate chains are used, all intermediate certificates up to, but not including the locally provisioned trust anchor certificate must be signaled. </del>  IPsec tunnel mode is required because the ACP will route/forward packets received from any other ACP node across the ACP secure

Reviewer comments:
During IETF 106 I solicited some feedback on the ACP IPsec/IKEv2 usage from Valery Smyslov; I've tried to digest that feedback into new text here. Some aspects are still subject to change. I also made a minor tweak to the DTLS section to bring it into parity with the IPsec one.
Merging first, then fixing.

Revised text:
6.7.1.  <ins> An ACP node announces its ability to support IPsec, negotiated via IKEv2, as the ACP secure channel protocol in GRASP as the "IKEv2" method for the "AN_ACP" objective. </ins> 6.7.1.1. To run ACP via IPsec natively, no further IANA assignments/ definitions are required.  <ins> The ACP usage of IPsec and IKEv2 mandates a narrow profile of the current standards-track usage guidance for IPsec RFC8221 and IKEv2 RFC8247.  This profile provides for stringent security properties and can exclude deprecated/legacy algorithms because there is no need for interoperability with legacy equipment for ACP channels.  Any such backward compatibility would lead only to increased attack surface and implementation complexity, for no benefit. An ACP node that is supporting native IPsec MUST use IPsec in tunnel mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next Header of 41).  It MUST use local and peer link-local IPv6 addresses for encapsulation.  Manual keying MUST NOT be used (independent of the security weaknesses of manual keying, it is incompatible with an autonomic platform). </ins> IPsec tunnel mode is required because the ACP will route/forward packets received from any other ACP node across the ACP secure
Original text:
transport mode, it would only be possible to send packets originated by the ACP node itself. <del> IKEv2 authentication MUST use authentication method=1 ("RSA Digital Signature") for ACP certificates with RSA key and methods 9,10,11 for ACP certificates with ECC key according to the keys size/curve. A certificate payload with the ACP certificate MUST be included during IKEv2 authentication to support the ACP domain membership as described in certcheck, because it is using additional elements of the ACP certificates.  ACP peers are expected to have the same set of Trust Anchors (TA), so a certificate path MUST only be included in the signaled payload when the path contains intermediate certificates not in the TA set, such as sub-CAs (see acp-registrars). IPsec MUST support ESP with ENCR_AES_GCM_16 (RFC4106) due to its higher performance over ENCR_AES_CBC.  ACP MUST NOT use any NULL encryption option due to the confidentiality of ACP payload that may not be encrypted by itself (when carrying legacy management protocol traffics as well as hop-by-hop GRASP).  These requirements are based on RFC8221 but limited to the minimum necessary options because there is no need for interoperability with legacy equipment for ACP channels, instead any such backward compatibility would reduce the minimum security or performance required for ACP channels or increase the implementation complexity of the ACP. </del>  Once there are updates to RFC8221, these should accordingly be reflected in updates to these ACP requirements, for example if

Reviewer comments:
During IETF 106 I solicited some feedback on the ACP IPsec/IKEv2 usage from Valery Smyslov; I've tried to digest that feedback into new text here. Some aspects are still subject to change. I also made a minor tweak to the DTLS section to bring it into parity with the IPsec one.
Merging first, then fixing.

Revised text:
transport mode, it would only be possible to send packets originated by the ACP node itself.  <ins> ACP IPsec implementations MUST support ESP with ENCR_AES_GCM_16 (RFC4106) due to its higher performance over ENCR_AES_CBC.  ACP MUST NOT use any NULL encryption option due to the confidentiality of ACP payload that may not be encrypted by itself (when carrying legacy management protocol traffics as well as hop-by-hop GRASP).  When using AES encryption, 256-bit keys MUST be used.  AES-GCM is an AEAD cipher mode, so no ESP authentication algorithm requirement is needed. </ins> Once there are updates to RFC8221, these should accordingly be reflected in updates to these ACP requirements, for example if
Original text:
long as they do not result in a reduction of security over the above MTI requirements.  For example, ESP compression MAY be used. <del> IKEv2 MUST follow RFC8247 as necessary to support the above listed IPsec requirements. </del>  6.7.1.2.

Reviewer comments:
During IETF 106 I solicited some feedback on the ACP IPsec/IKEv2 usage from Valery Smyslov; I've tried to digest that feedback into new text here. Some aspects are still subject to change. I also made a minor tweak to the DTLS section to bring it into parity with the IPsec one.
Merging first, then fixing.

Revised text:
long as they do not result in a reduction of security over the above MTI requirements.  For example, ESP compression MAY be used.  <ins> As for ESP (above), for IKEv2, the ENCR_AES_GCM_16 encryption algorithm (with 256-bit keys) MUST be supported.  The IKEv2 PRF_HMAC_SHA2_512 pseudorandom function MUST be supported. IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP) MUST be supported (in addition to 2048-bit MODP).  ECC provides a similar security level to finite-field (MODP) key exchange with a shorter key length, so is generally preferred absent other considerations. IKEv2 authentication MUST use the ACP domain certificates.  The Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be supported (see IKEV2IANA for this and other IANA IKEv2 parameter names used in this text).  If certificate chains are used, all intermediate certificates up to, but not including the locally provisioned trust anchor certificate must be signaled. A certificate payload with the ACP certificate MUST be included during IKEv2 authentication to support the ACP domain membership check as described in certcheck, because it is using additional elements of the ACP certificates.  ACP peers are expected to have the same set of Trust Anchors (TA), so a certificate path MUST only be included in the signaled payload when the path contains intermediate certificates not in the TA set, such as sub-CAs (see acp-registrars). ACP nodes are identified by their ACP address, so the ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST convey the ACP address.  If the peer's ACP domain certificate includes an ACP address in the domain information, the address in the identification payload must match the address in the certificate (allowing for the presence of virtualization bits in the ACP addressing scheme used). IKEv2 authentication MUST use authentication method 14 ("Digital Signature") for ACP certificates; this authentication method can be used with both RSA and ECDSA certificates, as indicated by a PKIX- style OID. The Digital Signature hash SHA2-512 MUST be supported (in addition to SHA2-256). Once there are updates to RFC8247, these should accordingly be reflected in updates to these ACP requirements, for example if ENCR_AES_GCM_16 was to be superceeded in the future or the key- exchange group recommendations are changed. Additional requirements from RFC8247 MAY be used for ACP channels as long as they do not result in a reduction of security over the above MTI requirements. </ins> 6.7.1.2.
Original text:
the first transport encryption supported in some classes of constrained devices.  To run ACP via UDP and DTLS v1.2 RFC6347 a locally assigned UDP port is used that is announced as a parameter in the GRASP AN_ACP objective to candidate neighbors.

Reviewer comments:
During IETF 106 I solicited some feedback on the ACP IPsec/IKEv2 usage from Valery Smyslov; I've tried to digest that feedback into new text here. Some aspects are still subject to change. I also made a minor tweak to the DTLS section to bring it into parity with the IPsec one.
Merging first, then fixing.

Revised text:
the first transport encryption supported in some classes of constrained devices. <ins> An ACP node announces its ability to support DTLS as the ACP secure channel protocol in GRASP as the "DTLS" method for the "AN_ACP" objective. </ins> To run ACP via UDP and DTLS v1.2 RFC6347 a locally assigned UDP port is used that is announced as a parameter in the GRASP AN_ACP objective to candidate neighbors.
Original text:
1. Bootstrapping Remote Secure Key Infrastructures BRSKI specifies <del> automated bootstrapping of an Autonomic Control Plane.  BRSKI Section 2.7 describes how a pledge "MAY contact a well-known URI of a cloud registrar if a local registrar cannot be discovered or if the pledge's target use cases do not include a local registrar". </del>  This document further specifies use of a BRSKI cloud registrar and clarifies operations that are not sufficiently specified in BRSKI.

Reviewer comments:
Not quite. It specifies secure bootstrapping of the individual nodes. It's RFC 8994 that bootstraps the ACP.

Revised text:
1. Bootstrapping Remote Secure Key Infrastructures BRSKI specifies  <ins> automated network onboarding of devices, referred to as pledges, within an Autonomic Control Plane or other managed network infrastructure.  BRSKI Section 2.7 describes how a pledge "MAY contact a well-known URI of a cloud registrar if a local registrar cannot be discovered or if the pledge's target use cases do not include a local registrar". </ins> This document further specifies use of a BRSKI cloud registrar and clarifies operations that are not sufficiently specified in BRSKI.
Original text:
logically separate entities.  The two functions could of course be integrated into a single service. <del> TWO CHOICES: 1.  Cloud Registrar redirects to Owner Registrar 2. Cloud Registrar returns VOUCHER pinning Owner Register. </del>  2.1.

Reviewer comments:
I find the "??" in the figure confusing. The Cloud Registrar and the MASA could just be shown as adjacent boxes; the explanation in the text is fine. That looks ugly as a single pseudo-sentence, and I'm not sure what it means. A more complete explanation would be good.

Revised text:
logically separate entities.  The two functions could of course be integrated into a single service.  <ins> There are two different mechanisms for a cloud registrar to handle voucher requests: 1. the Cloud Registrar redirects the request to Owner Registrar for handling 2. the Cloud Registrar returns a voucher pinning the Owner Register and includes additional bootstrapping information embedded in the voucher Both mechanisms are described in detail later in this document. </ins> 2.1.
Original text:
<del> CAPPORT Architecture </del>  draft-ietf-capport-architecture-08 Abstract <del> This document describes a CAPPORT architecture.  DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </del>  1.

Reviewer comments:
This replaces all mentions of capport (other than document slugs) with "captive portal". Note: this change includes the title of the document.
Joel Halpern writes, We should do this.
Or erase all mentions of 'capport'

Revised text:
 <ins> Captive Portal Architecture </ins> draft-ietf-capport-architecture-08 Abstract  <ins> This document describes a captive portal architecture.  DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </ins> 1.
Original text:
2.2.1. A standard for providing a portal URI using DHCP or Router <del> Advertisements is described in RFC7710bis.  The CAPPORT architecture expects this URI to indicate the API described in section_api. </del>  2.2.2.

Reviewer comments:
This replaces all mentions of capport (other than document slugs) with "captive portal". Note: this change includes the title of the document.
Joel Halpern writes, We should do this.
Or erase all mentions of 'capport'

Revised text:
2.2.1. A standard for providing a portal URI using DHCP or Router  <ins> Advertisements is described in RFC7710bis.  The captive portal architecture expects this URI to indicate the API described in section_api. </ins> 2.2.2.
Original text:
A side-benefit of the architecture described in this document is that devices without user interfaces are able to identify parameters of <del> captivity.  However, this document does not yet describe a mechanism for such devices to escape captivity. </del>  The architecture uses the following mechanisms:

Reviewer comments:
Multiple reviewers objected to the way in which we captured interactions with headless/UI-less devices. Clarify the document's intent. Do this by removing language that indicated that we would eventually get around to adding the requirements, and specify explicitly that we are not handling devices without UIs.
Eric points out in his review: He suggests as a solution: I propose we do this. The first mention is in section one. We can say something along the lines of "A future document could provide a solution for devices without user interfaces. This document focuses on devices with user interfaces."
On page 4: Joel Halpern writes,
We might want to avoid relying on the captivity concept so heavily, but this is a good change nonetheless.

Revised text:
A side-benefit of the architecture described in this document is that devices without user interfaces are able to identify parameters of  <ins> captivity.  However, this document does not describe a mechanism for such devices to negotiate for unrestricted network access.  A future document could provide a solution to devices without user interfaces. This document focuses on devices with user interfaces. </ins> The architecture uses the following mechanisms:
Original text:
section_capport_enforcement, until site-specific requirements have been met. <del> At this time we consider only devices with web browsers, with web </del>  applications being the means of satisfying Captive Portal Conditions. <del> An example interactive User Equipment is a smart phone. </del>  The User Equipment:

Reviewer comments:
Multiple reviewers objected to the way in which we captured interactions with headless/UI-less devices. Clarify the document's intent. Do this by removing language that indicated that we would eventually get around to adding the requirements, and specify explicitly that we are not handling devices without UIs.
Eric points out in his review: He suggests as a solution: I propose we do this. The first mention is in section one. We can say something along the lines of "A future document could provide a solution for devices without user interfaces. This document focuses on devices with user interfaces."
On page 4: Joel Halpern writes,
We might want to avoid relying on the captivity concept so heavily, but this is a good change nonetheless.

Revised text:
section_capport_enforcement, until site-specific requirements have been met.  <ins> This document only considers devices with web browsers, with web </ins> applications being the means of satisfying Captive Portal Conditions.  <ins> An example of such User Equipment is a smart phone. </ins> The User Equipment: