jiebi/TextFlow huggingface dataset:
Original text:
A Captive Portal API needs to present information to clients that is unique to that client.  To do this, some systems use information from the context of a request, such as the source address, to identify the <del> UE. </del>  Using information from context rather than information from the URI allows the same URI to be used for different clients.  However, it also means that the resource is unable to provide relevant <del> information if the UE makes a request using a different network path. This might happen when UE has multiple network interfaces.  It might also happen if the address of the API provided by DNS depends on where the query originates (as in split DNS RFC8499). </del>  Accessing the API MAY depend on contextual information.  However, the <del> URIs provided in the API SHOULD be unique to the UE and not dependent on contextual information to function correctly. Though a URI might still correctly resolve when the UE makes the request from a different network, it is possible that some functions could be limited to when the UE makes requests using the captive network.  For example, payment options could be absent or a warning could be displayed to indicate the payment is not for the current connection. </del>  URIs could include some means of identifying the User Equipment in the URIs.  However, including unauthenticated User Equipment

Reviewer comments:
We only use UE in one section. Everywhere else we use User Equipment. Expand UE in that section so we are consistent with our use of it.
It was pointed out that we sometimes use UE rather than user equipment (e.g. section 3.5.). Let's be consistent, perhaps shortening all references to UE other than where it is defined.

Revised text:
A Captive Portal API needs to present information to clients that is unique to that client.  To do this, some systems use information from the context of a request, such as the source address, to identify the  <ins> User Equipment. </ins> Using information from context rather than information from the URI allows the same URI to be used for different clients.  However, it also means that the resource is unable to provide relevant  <ins> information if the User Equipment makes a request using a different network path.  This might happen when User Equipment has multiple network interfaces.  It might also happen if the address of the API provided by DNS depends on where the query originates (as in split DNS RFC8499). </ins> Accessing the API MAY depend on contextual information.  However, the  <ins> URIs provided in the API SHOULD be unique to the User Equipment and not dependent on contextual information to function correctly. Though a URI might still correctly resolve when the User Equipment makes the request from a different network, it is possible that some functions could be limited to when the User Equipment makes requests using the captive network.  For example, payment options could be absent or a warning could be displayed to indicate the payment is not for the current connection. </ins> URIs could include some means of identifying the User Equipment in the URIs.  However, including unauthenticated User Equipment
Original text:
Captive Portal Signaling Protocol: Also known as Signaling Protocol. The protocol for communicating Captive Portal Signals.  2. 2.1.

Reviewer comments:
The idea of a session is important, both because it is used in the API document, and because it helps to tie everything together. Define it in the terminology.
This is a first stab at defining the session. I suspect we may need to iterate on it once or twice. Let me know if you think it deserves its own section on top of the terminology.
Thanks for doing this! Here’s a suggested alternate way to explain this. Feel free to modify as desired. Captive Portal Session: Also referred to simply as the “session”, a Captive Portal Session is the association for a particular User Equipment that starts when it interacts with the Captive Portal and gains open access to the network, and ends when the User Equipment moves back into the original captive state. The Captive Network maintains the state of each active Session, and can limit Sessions based on a length of time or a number of bytes used. The Session is associated with a particular User Equipment using the User Equipment's identifier (see ).
Your phrasing is better. It manages to work in the session limits while keeping it about the same lenght. I've taken it almost verbatim. NAME Do you have any input on this topic?
From Ben's review of the API document, we should define "session" formally in the architecture. The architecture doc mentions it in passing once already. The API doc uses the term session much more.

Revised text:
Captive Portal Signaling Protocol: Also known as Signaling Protocol. The protocol for communicating Captive Portal Signals. <ins> Captive Portal Session: Also referred to simply as the "session", a Captive Portal Session is the association for a particular User Equipment that starts when it interacts with the Captive Portal and gains open access to the network, and ends when the User Equipment moves back into the original captive state.  The Captive Network maintains the state of each active Session, and can limit Sessions based on a length of time or a number of bytes used.  The Session is associated with a particular User Equipment using the User Equipment's identifier (see ue_identity). </ins> 2. 2.1.
Original text:
Architecture RFC7556 provides some discussion on authenticating an operator. <del> Given that a user chooses to visit a Captive Portal URI, the URI location SHOULD be securely provided to the user's device.  E.g., the DHCPv6 AUTH option can sign this information. </del>  If a user decides to incorrectly trust an attacking network, they might be convinced to visit an attacking web page and unwittingly

Reviewer comments:
The language of this section was hard for some of the reviewers to understand. Rephrase it to be more explicit and clear.
Yes. We should probably rephrase this. E.g. "The user makes an informed choice in deciding to visit and trust the Captive Portal URI. Since the network provides Captive Portal URI to the user equipment, thenetwork SHOULD do so securely so that the user's trust in the network can extend to their trust of the Captive Portal URI. E.g., the DHCPv6 AUTH option can sign this information."

Revised text:
Architecture RFC7556 provides some discussion on authenticating an operator.  <ins> The user makes an informed choice to visit and trust the Captive Portal URI.  Since the network provides Captive Portal URI to the user equipment, the network SHOULD do so securely so that the user's trust in the network can extend to their trust of the Captive Portal URI.  E.g., the DHCPv6 AUTH option can sign this information. </ins> If a user decides to incorrectly trust an attacking network, they might be convinced to visit an attacking web page and unwittingly
Original text:
This document describes an architecture for implementing captive portals while addressing most of the problems arising for current captive portal mechanisms.  The architecture is guided by these <del> principles: </del>  A side-benefit of the architecture described in this document is that devices without user interfaces are able to identify parameters of

Reviewer comments:
Attempting to fix issue . I attempted to reword the principles, adding more prose for the rationale. Also upgraded some SHOULD NOT to MUST NOT because it seems some people thought the SHOULD NOT says the existing approach is OK. These are just some ideas. I won't be offended if rejected.
I believe I addressed all comments. You'll probably want to review the complete diff again.
Benjamin writes in his review: Michael replied with this suggested text: This seems reasonable, as I mentioned in the reply. We should go with it, unless anyone has an objection. Also, attribute it to Michael Richardson.
S. Moonesamy writes
One approach I suggested in my reply to the feedback:
This is good. Thanks for sorting through this; it's important that this is right, and you have cleared it up a lot.Much clearer. Thanks!

Revised text:
This document describes an architecture for implementing captive portals while addressing most of the problems arising for current captive portal mechanisms.  The architecture is guided by these  <ins> requirements: </ins> A side-benefit of the architecture described in this document is that devices without user interfaces are able to identify parameters of
Original text:
The authors thank Benjamin Kaduk for providing the content related to TLS certificate validation of the API server.  The authors thank various individuals for their feedback on the mailing list and during the IETF98 hackathon: David Bird, Erik Kline, Alexis La Goulette, Alex Roscoe, Darshak Thakore, and Vincent van

Reviewer comments:
Attempting to fix issue . I attempted to reword the principles, adding more prose for the rationale. Also upgraded some SHOULD NOT to MUST NOT because it seems some people thought the SHOULD NOT says the existing approach is OK. These are just some ideas. I won't be offended if rejected.
I believe I addressed all comments. You'll probably want to review the complete diff again.
Benjamin writes in his review: Michael replied with this suggested text: This seems reasonable, as I mentioned in the reply. We should go with it, unless anyone has an objection. Also, attribute it to Michael Richardson.
S. Moonesamy writes
One approach I suggested in my reply to the feedback:
This is good. Thanks for sorting through this; it's important that this is right, and you have cleared it up a lot.Much clearer. Thanks!

Revised text:
The authors thank Benjamin Kaduk for providing the content related to TLS certificate validation of the API server. <ins> The authors thank Michael Richardson for providing wording requiring DNSSEC and TLS to operate without the user adding exceptions. </ins> The authors thank various individuals for their feedback on the mailing list and during the IETF98 hackathon: David Bird, Erik Kline, Alexis La Goulette, Alex Roscoe, Darshak Thakore, and Vincent van
Original text:
The API MUST ensure the integrity of this information, as well as its confidentiality.  7.4. If a Signaling Protocol is implemented, it may be possible for any

Reviewer comments:
One of the reviewers asked for more information about the attacker in section 7.3. This does so, describing what the attacker could achieve by compromising the security.
Benjamin writes, Without knowing the details of the particular solution, it's a bit hard to say for sure, but roughly I'd say it's someone who wants to interact with the API using the identity of the user. E.g. if we're using an 'unguessable' URI, an attacker snooping on the communication with the API could determine the URI, and use it.

Revised text:
The API MUST ensure the integrity of this information, as well as its confidentiality. <ins> An attacker with access to this information might be able to masquerade as a specific User Equipment when interacting with the API, which could then allow them to masquerade as that User Equipment when interacting with the User Portal.  This could give them the ability to determine whether the User Equipment has accessed the portal, or deny the User Equipment service by ending their session using mechanisms provided by the User Portal, or consume that User Equipment's quota.  An attacker with the ability to modify the information could deny service to the User Equipment, or cause them to appear as a different User Equipment. </ins> 7.4. If a Signaling Protocol is implemented, it may be possible for any
Original text:
2.5. <del> User Equipment may send traffic to hosts blocked by the captive network prior to the Enforcement device granting it access.  The Enforcement Device rightly blocks or resets these requests.  However, in the absence of a signal from the Enforcement Device or interaction with the API server, the User Equipment can only guess at whether it is captive.  Consequently, allowing the Enforcement Device to explicitly signal to the User Equipment that the traffic is being blocked may improve the user's experience. An Enforcement Device may also want to notify the User Equipment of a pending expiry of its access to the external network, so providing the Enforcement Device the ability to preemptively signal may be desirable. A specific Captive Portal Signaling Protocol is out of scope for this document.  However, in order to ensure that future protocols fit into the architecture, requirements for a Captive Portal Signaling Protocol follow: The Captive Portal Signaling Protocol does not provide any means of indicating that the network prevents access to some destinations. The intent is to rely on the Captive Portal API and the web portal to which it points to communicate local network policies. The Captive Portal Enforcement function MAY send Captive Portal Signals when User Equipment that has not satisfied the Captive Portal Conditions attempts to send traffic to the network.  These signals MUST be rate-limited to a configurable rate. The signals MUST NOT be sent to the destinations/peers that the User Equipment is restricted from accessing.  The indications are only to be sent to the User Equipment. </del>  2.6.

Reviewer comments:
The working group has decided that we do not need to tackle specifying the signaling protocol. Rather than leaving the document with it partially specified, remove most of the text related to it. Keep some basic examples of constraints. This also removes the text which claimed that the document would specify rqeuirements for the protocol. It does not. Made a few related editorial changes.
As suggested by NAME : Do a pass through the document with this text in mind and make sure it makes sense. Clean up anything that may have depended on removed text.
Thanks for putting this together. This seems sufficient, and brief.

Revised text:
2.5.  <ins> When User Equipment first connects to a network, or when there are changes in status, the Enforcement Device could generate a signal toward the User Equipment.  This signal indicates that the User Equipment might need to contact the API Server to receive updated information.  For instance, this signal might be generated when the end of a session is imminent, or when network access was denied. An Enforcement Device MUST rate-limit any signal generated in response to these conditions.  See section_signal_risks for a discussion of risks related to a Captive Portal Signal. </ins> 2.6.
Original text:
7.5. <del> The Signal could inform the User Equipment that it is being held captive.  There is no requirement that the User Equipment do something about this.  Devices MAY permit users to disable automatic reaction to captive-portal indications for privacy reasons.  However, there would be the trade-off that the user doesn't get notified when network access is restricted.  Hence, end-user devices MAY allow users to manually control captive portal interactions, possibly on the granularity of Provisioning Domains. </del> 

Reviewer comments:
The working group has decided that we do not need to tackle specifying the signaling protocol. Rather than leaving the document with it partially specified, remove most of the text related to it. Keep some basic examples of constraints. This also removes the text which claimed that the document would specify rqeuirements for the protocol. It does not. Made a few related editorial changes.
As suggested by NAME : Do a pass through the document with this text in mind and make sure it makes sense. Clean up anything that may have depended on removed text.
Thanks for putting this together. This seems sufficient, and brief.

Revised text:
7.5.  <ins> The Captive Portal Signal could inform the User Equipment that it is being held captive.  There is no requirement that the User Equipment do something about this.  Devices MAY permit users to disable automatic reaction to Captive Portal Signals indications for privacy reasons.  However, there would be the trade-off that the user doesn't get notified when network access is restricted.  Hence, end-user devices MAY allow users to manually control captive portal interactions, possibly on the granularity of Provisioning Domains. </ins>
Original text:
information, expiry time, method of providing credentials, security token for validating ICMP messages. <del> This document does not specify the details of the API. </del>  <del> The CAPPORT API MUST support TLS for privacy and server authentication. </del>  2.4.

Reviewer comments:
We want to make TLS a requirement, not a suggestion, so I've chagned the wording around TLS to reflect this. I also added a section to the security section discussing the motivation behind the requirement.
Can you forward to the list please?

Revised text:
information, expiry time, method of providing credentials, security token for validating ICMP messages.  <ins> The API MUST use TLS for privacy and server authentication.  The implementation of the API MUST ensure both privacy and integrity of any information provided by or required by it. </ins>  <ins> This document does not specify the details of the API. </ins> 2.4.
Original text:
5.2. The solution described here assumes that when the User Equipment <del> needs to trust the API server, server authentication will be utilized using TLS mechanisms. </del>  5.3.  It is possible for any user on the Internet to send ICMP packets in an attempt to cause the receiving equipment to go to the captive portal.  This has been considered and addressed in the following

Reviewer comments:
We want to make TLS a requirement, not a suggestion, so I've chagned the wording around TLS to reflect this. I also added a section to the security section discussing the motivation behind the requirement.
Can you forward to the list please?

Revised text:
5.2. The solution described here assumes that when the User Equipment  <ins> needs to trust the API server, server authentication will be performed using TLS mechanisms. </ins> 5.3. <ins> The solution described here requires that the API be secured using TLS.  This is required to allow the user equipment and API server to exchange secrets which can be used to validate future interactions. The API must ensure the integrity of this information, as well as its confidentiality. 5.4. </ins> It is possible for any user on the Internet to send ICMP packets in an attempt to cause the receiving equipment to go to the captive portal.  This has been considered and addressed in the following
Original text:
Even when redirected, the User Equipment securely authenticates with API servers. <del> 5.4. </del>  The ICMP messaging informs the User Equipment that it is being held captive.  There is no requirement that the User Equipment do

Reviewer comments:
We want to make TLS a requirement, not a suggestion, so I've chagned the wording around TLS to reflect this. I also added a section to the security section discussing the motivation behind the requirement.
Can you forward to the list please?

Revised text:
Even when redirected, the User Equipment securely authenticates with API servers.  <ins> 5.5. </ins> The ICMP messaging informs the User Equipment that it is being held captive.  There is no requirement that the User Equipment do
Original text:
The User Equipment accesses the network until conditions Expire. <del> 3.2. </del>  This section describes a possible work-flow when conditions expire and the user visits the portal again (e.g., low quota, or time

Reviewer comments:
We need to discuss what information will be used to identify the UE from the perspective of the various components in the system. This updates the draft to discuss this concept, including desired properties of the identifier and some examples. This aims to address issue 5 (URL)

Revised text:
The User Equipment accesses the network until conditions Expire.  <ins> 4.2. </ins> This section describes a possible work-flow when conditions expire and the user visits the portal again (e.g., low quota, or time
Original text:
The User Equipment accesses the external network. <del> 4. </del>  This memo includes no request to IANA. <del> 5. </del>  <del> 5.1. </del>  When joining a network, some trust is placed in the network operator. This is usually considered to be a decision by a user on the basis of

Reviewer comments:
We need to discuss what information will be used to identify the UE from the perspective of the various components in the system. This updates the draft to discuss this concept, including desired properties of the identifier and some examples. This aims to address issue 5 (URL)

Revised text:
The User Equipment accesses the external network.  <ins> 5. </ins> This memo includes no request to IANA.  <ins> 6. </ins>  <ins> 6.1. </ins> When joining a network, some trust is placed in the network operator. This is usually considered to be a decision by a user on the basis of
Original text:
provide credentials to an attacker.  Browsers can authenticate servers but cannot detect cleverly misspelled domains, for example. <del> 5.2. </del>  The solution described here assumes that when the User Equipment needs to trust the API server, server authentication will be performed using TLS mechanisms. <del> 5.3. </del>  The solution described here requires that the API be secured using TLS.  This is required to allow the user equipment and API server to

Reviewer comments:
We need to discuss what information will be used to identify the UE from the perspective of the various components in the system. This updates the draft to discuss this concept, including desired properties of the identifier and some examples. This aims to address issue 5 (URL)

Revised text:
provide credentials to an attacker.  Browsers can authenticate servers but cannot detect cleverly misspelled domains, for example.  <ins> 6.2. </ins> The solution described here assumes that when the User Equipment needs to trust the API server, server authentication will be performed using TLS mechanisms.  <ins> 6.3. </ins> The solution described here requires that the API be secured using TLS.  This is required to allow the user equipment and API server to
Original text:
The API must ensure the integrity of this information, as well as its confidentiality. <del> 5.4. </del>  It is possible for any user on the Internet to send ICMP packets in an attempt to cause the receiving equipment to go to the captive

Reviewer comments:
We need to discuss what information will be used to identify the UE from the perspective of the various components in the system. This updates the draft to discuss this concept, including desired properties of the identifier and some examples. This aims to address issue 5 (URL)

Revised text:
The API must ensure the integrity of this information, as well as its confidentiality.  <ins> 6.4. </ins> It is possible for any user on the Internet to send ICMP packets in an attempt to cause the receiving equipment to go to the captive
Original text:
Even when redirected, the User Equipment securely authenticates with API servers. <del> 5.5. </del>  The ICMP messaging informs the User Equipment that it is being held captive.  There is no requirement that the User Equipment do

Reviewer comments:
We need to discuss what information will be used to identify the UE from the perspective of the various components in the system. This updates the draft to discuss this concept, including desired properties of the identifier and some examples. This aims to address issue 5 (URL)

Revised text:
Even when redirected, the User Equipment securely authenticates with API servers.  <ins> 6.5. </ins> The ICMP messaging informs the User Equipment that it is being held captive.  There is no requirement that the User Equipment do