jiebi/TextFlow huggingface dataset:
Original text:
Captive Portal User Equipment: Also known as User Equipment.  A device which has voluntarily joined a network for purposes of <del> communicating beyond the constraints of the captive network. </del>  User Portal: The web server providing a user interface for assisting the user in satisfying the conditions to escape captivity. The User Equipment: None of the above requirements are mandatory because (a) we do not <del> wish to say users or devices must seek full access to the captive network, (b) the requirements may be fulfilled by manually visiting </del>  the captive portal web application, and (c) legacy devices must continue to be supported. 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 <del> using the captive network.  For example, payment options could be </del>  absent or a warning could be displayed to indicate the payment is not for the current connection.

Reviewer comments:
A reviewer found a problem with some phrasing, and also noticed that we missed a few captive networks. Clean them up.

Revised text:
Captive Portal User Equipment: Also known as User Equipment.  A device which has voluntarily joined a network for purposes of  <ins> communicating beyond the constraints of the Captive Portal. </ins> User Portal: The web server providing a user interface for assisting the user in satisfying the conditions to escape captivity. The User Equipment: None of the above requirements are mandatory because (a) we do not  <ins> wish to say users or devices must seek full access to the Captive Portal, (b) the requirements may be fulfilled by manually visiting </ins> the captive portal web application, and (c) legacy devices must continue to be supported. 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  <ins> using the Captive Portal.  For example, payment options could be </ins> absent or a warning could be displayed to indicate the payment is not for the current connection.
Original text:
Be Visible to the Enforcement Device  3.2.1. In order to uniquely identify the User Equipment, at most one user

Reviewer comments:
Fixes Issue
NAME Thanks for the quick review.
The information needs to only apply to the current point of network attachment. That is obvious, perhaps, but worth stating. Thanks to Warren Kumari.
NAME Can you take a look at PR ? I want to make sure I've captured Warren's point properly.
I think that's about right. But you should avoid 2119 language. I have a few suggestions (if only GitHub had multi-line suggestions...).

Revised text:
Be Visible to the Enforcement Device <ins> An identifier might only apply to the current point of network attachment.  If the device moves to a different network location its identity could change. </ins> 3.2.1. In order to uniquely identify the User Equipment, at most one user
Original text:
indication that traffic is restricted, which can be used as a prompt to contact the API.  The Captive Portal Enforcement function MAY send Captive Portal Signals when disallowed User Equipment attempts to send to the network.  These signals MUST be rate-limited to a configurable rate.

Reviewer comments:
Point out that future Captive Portal Signalling Protocols will not enable non-binary blocking. Fixes Issue
There are networks that want to selectively block things. We aren't going to get consensus on whether that is good practice, but we do have consensus that we don't provide protocol mechanisms for communicating about selective blocking. Document that fact.
Closed in .

Revised text:
indication that traffic is restricted, which can be used as a prompt to contact the API. <ins> 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. </ins> The Captive Portal Enforcement function MAY send Captive Portal Signals when disallowed User Equipment attempts to send to the network.  These signals MUST be rate-limited to a configurable rate.
Original text:
2.2.2. <del> Although still a work in progress, I-D.ietf-intarea-provisioning- domains proposes a mechanism for User Equipment to be provided with PvD Bootstrap Information containing the URI for a JSON file containing key-value pairs to be downloaded over HTTPS.  This JSON file would fill the role of the Captive Portal API described in section_api. </del>  The PvD security model provides secure binding between the information provided by the trusted Router Advertisement and the

Reviewer comments:
PvD is almost certainly going to be published first, so remove the lead-in to it in preparation for integrating the full rfc soon.
When the document says: It might be better to just remove the lead-in part, since it appears PvD will be published ahead of this document.

Revised text:
2.2.2.  <ins> I-D.ietf-intarea-provisioning-domains proposes a mechanism for User Equipment to be provided with PvD Bootstrap Information containing the URI for a JSON file containing key-value pairs to be downloaded over HTTPS.  This JSON file would fill the role of the Captive Portal API described in section_api. </ins> The PvD security model provides secure binding between the information provided by the trusted Router Advertisement and the
Original text:
CAPPORT Architecture <del> draft-ietf-capport-architecture-04 </del>  Abstract

Reviewer comments:
Bump the version of the draft in preparation for submission. This version picks up: An editorial change related to pvds A description of what to do when the captive portal URI changes.

Revised text:
CAPPORT Architecture  <ins> draft-ietf-capport-architecture-05 </ins> Abstract
Original text:
2.2.1. A standard for providing a portal URI using DHCP or Router <del> Advertisements is described in RFC7710.  The CAPPORT architecture </del>  expects this URI to indicate the API described in section_api. Although it is not clear from RFC7710 what protocol should be

Reviewer comments:
Note that this leaves this paragraph intact: That paragraph probably needs to go based on what is in 7710bis now.
And remove some of the stuff that is speculative from SS2.2.1.

Revised text:
2.2.1. A standard for providing a portal URI using DHCP or Router  <ins> Advertisements is described in RFC7710bis.  The CAPPORT architecture </ins> expects this URI to indicate the API described in section_api. Although it is not clear from RFC7710 what protocol should be
Original text:
2.2.1. A standard for providing a portal URI using DHCP or Router <del> Advertisements is described in RFC7710.  The CAPPORT architecture </del>  expects this URI to indicate the API described in section_api. <del> Although it is not clear from RFC7710 what protocol should be executed at the specified URI, some readers might have assumed it to be an HTML page, and hence there might be User Equipment assuming a browser should open this URI.  For backwards compatibility, it is RECOMMENDED that the server check the "Accept" field when serving the URI, and serve HTML pages for "text/html" and serve the API for "application/json".  [REVISIT: are these details appropriate?] </del> 2.2.2. Although still a work in progress, I-D.pfister-capport-pvd proposes a Information containing the URI for the JSON-based API described in section_api. <del> The PvD security model provides secure binding between the information provided by the trusted Router Advertisement and the HTTPS server. </del> 2.3. The purpose of a Captive Portal API is to permit a query of Captive

Reviewer comments:
This removes some text around discovering URLs with 7710[bis] and PvD. That extra context can be handled by those documents. This builds on .
Looks good
Lgtm
LGTM

Revised text:
2.2.1. A standard for providing a portal URI using DHCP or Router  <ins> Advertisements is described in RFC7710bis.  The CAPPORT architecture </ins> expects this URI to indicate the API described in section_api.  2.2.2. Although still a work in progress, I-D.pfister-capport-pvd proposes a Information containing the URI for the JSON-based API described in section_api.  2.3. The purpose of a Captive Portal API is to permit a query of Captive
Original text:
URLs is correct and meaningful to the User Equipment, even when accessed from a network other than the one that contains the captive portal.  One consequence of this is that URLs provided in the API are <del> expected to be resolved using public DNS. </del>  Though a URL might still correctly resolve when the UE makes the request from a different network, it is possible that some functions

Reviewer comments:
URL provides a definition of "Global DNS" to which we might want to link.
Thanks!

Revised text:
URLs is correct and meaningful to the User Equipment, even when accessed from a network other than the one that contains the captive portal.  One consequence of this is that URLs provided in the API are  <ins> expected to be resolved using public global DNS (as defined in Section 2 of RFC8499). </ins> Though a URL might still correctly resolve when the UE makes the request from a different network, it is possible that some functions
Original text:
block traffic, and some method to alert the user.  Common methods of alerting the user involve modifying HTTP or DNS traffic. <del> Problems with captive portal implementations have been described in I-D.nottingham-capport-problem.  [If that document cannot be published, consider putting its best parts into an appendix of this document.] </del> This document standardizes an architecture for implementing captive portals that provides tools for addressing most of those problems. We are guided by these principles:

Reviewer comments:
This was an old, expired submission, unlikely to be revived. The intro provides enough context about what is wrong with captive portals. A problem statement rfc could always be made in the future if necessary, so let's just keep this document focused on the solution.
This paragraph still exists in the document: Problems with captive portal implementations have been described in [I-D.nottingham-capport-problem]. [If that document cannot be published, consider putting its best parts into an appendix of this document.] Maybe pull in sections 3 & 4 from URL ?
NAME I'm fine taking Dave's suggestion to pull in those sections. However, I'm not sure of the best way to attribute the content to that original document/its author. I imagine simply acknowledging Mark is sufficient, but if there is a better practice, please let me know.
Though I am somewhat concerned that it's a lot of text, and could be contentious if we're adding it after last call. For example statements like the one about access only being possible to steal in an insecure wireless network--I'm not convinced that's actually true. Given that this document wasn't really vetted, perhaps it'd be better to just try to summarize in the intro some of the more salient points.
Yes, if we pull in additional text, then I might feel obligated to run another last call. We can ask Mark for permission (not at-mentioning here yet), but I want to understand what this document lacks that Mark's has. My sense is that the text can be just cut, or the problem statement summarized in one of two paragraphs.
Good question. I think the nottingham problem statement was very useful for thinking about the problem and what to avoid. But we do have the guiding principles in the introduction. It would certainly be easier to just drop the mention of it, and focus on what should be vs. what should not be.

Revised text:
block traffic, and some method to alert the user.  Common methods of alerting the user involve modifying HTTP or DNS traffic.  This document standardizes an architecture for implementing captive portals that provides tools for addressing most of those problems. We are guided by these principles:
Original text:
the captive portal web application, and (c) legacy devices must continue to be supported.  2.2. Here we discuss candidate mechanisms for provisioning the User

Reviewer comments:
I'll merge this later today when I go over it and submit the new draft then.
NAME Done.
Thanks! IESG here we come.
The CAPPORT API document explains some requirements on deployments to allow certificate validation of servers, specifically in Section 4.1.1. Server Authentication. Last call comments noted that the architecture should have notes that such provisions are needed.
This appears to be the last PR active on the respository. Can we have an updated version of the draft please?Thanks!

Revised text:
the captive portal web application, and (c) legacy devices must continue to be supported. <ins> If User Equipment supports the Captive Portal API, it MUST validate API server TLS certificate (see RFC2818).  An Enforcement device SHOULD allow access to any services that User Equipment could need to contact to perform certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf-capport-api for more information.  If certificate validation fails, User Equipment MUST NOT proceed with any of the behavior described above. </ins> 2.2. Here we discuss candidate mechanisms for provisioning the User
Original text:
The entries in the registry are: The values in this registry shall be allocated under "IETF Review" <del> policy for values strictly smaller than 64, under "Specification Required" policy for values 64-223, and under "Private Use" otherwise (see RFC8126 for the definition of relevant policies). </del>  The procedures for requesting values in the Specification Required space are specified in I-D.ietf-tls-iana-registry-updates.

Reviewer comments:
It's been pointed out that one byte may not be sufficient to run experimental compression algorithms without collisions. Expand the space to 2^16 values, and update the IANA considerations section accordingly.
NAME suggested expanding the compression code point from 1 byte to 2.
Do we really want to do that? I can write up a PR, but I don't really see us ever having more than 20 of those... Old compression types took up only one byte; I expect us to have more, because dictionaries, but not much more, because realistically there are only so many codepoints we can deploy.
Since it was mentioned at the meeting I thought I create an issue so it can be discussed. I'm fine closing since I agree we probably don't need this, unless NAME or someone else has a reason for doing this (and we can reopen later if needed).
I suggested expanding this due to the potential future use of dictionaries. I agree we will likely never have more than 20 standardized code points, but 1 byte is a bit low for experimental use without worry of collision. 1 byte is probably enough, but 2 bytes would definitely be enough, and the cost of 1 extra byte seems pretty low to me.
Fixed in .
Added comment, otherwise lgtm.

Revised text:
The entries in the registry are: The values in this registry shall be allocated under "IETF Review"  <ins> policy for values strictly smaller than 256, under "Specification Required" policy for values 256-16383, and under "Experimental Use" otherwise (see RFC8126 for the definition of relevant policies). Experimental Use extensions can be used both on private networks and over the open Internet. </ins> The procedures for requesting values in the Specification Required space are specified in I-D.ietf-tls-iana-registry-updates.
Original text:
<del> Transport Layer Security (TLS) Certificate Compression </del>  draft-ietf-tls-certificate-compression-latest Abstract <del> In Transport Layer Security (TLS) handshakes, certificate chains often take up the majority of the bytes transmitted. </del>  This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. 1. In order to reduce latency and improve performance it can be useful <del> to reduce the amount of data exchanged during a Transport Layer Security (TLS) handshake. </del>  RFC7924 describes a mechanism that allows a client and a server to avoid transmitting certificates already shared in an earlier

Reviewer comments:
Now that TLS and DTLS are in the RFC editor's list of abbreviations as "common" there's no need to spell out Transport Layer Security anymore.

Revised text:
 <ins> TLS Certificate Compression </ins> draft-ietf-tls-certificate-compression-latest Abstract  <ins> In TLS handshakes, certificate chains often take up the majority of the bytes transmitted. </ins> This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. 1. In order to reduce latency and improve performance it can be useful  <ins> to reduce the amount of data exchanged during a TLS handshake. </ins> RFC7924 describes a mechanism that allows a client and a server to avoid transmitting certificates already shared in an earlier
Original text:
the verification have the same security properties as they would have in TLS normally.  Since certificate chains are typically presented on a per-server name or per-user basis, the attacker does not have control over any individual fragments in the Certificate message, meaning that they

Reviewer comments:
Thanks for doing this NAME I ended up being tied up in a bunch of other stuff.
See message on mailing list from NAME for more details: URL
Do we actually have consensus for this requiring a mitigation?
I probably worded the title wrong. I created this just to keep track of the issue.
lgtm

Revised text:
the verification have the same security properties as they would have in TLS normally. <ins> In order for certificate compression to function correctly, the underlying compression algorithm MUST be deterministic and it MUST output the same data that was provided as input by the peer. </ins> Since certificate chains are typically presented on a per-server name or per-user basis, the attacker does not have control over any individual fragments in the Certificate message, meaning that they
Original text:
that is lower than that; in both cases, they MUST apply the same limit as if no compression were used.  6. It's been observed that a significant number of middleboxes intercept

Reviewer comments:
LGTM. NAME can you accept NAME suggestion? I can't do that myself as the branch is on a separate repo. Then it's ready to merge I think.

Revised text:
that is lower than that; in both cases, they MUST apply the same limit as if no compression were used. <ins> While the Certificate message in TLS 1.3 is encrypted, third parties can draw inferences from the message length observed on the wire. TLS 1.3 provides a padding mechanism (discussed in Sections 5.4 and E.3 of RFC8446) to counteract such analysis.  Certificate compression alters the length of the Certificate message, and the change in length is dependent on the actual contents of the certificate.  Any padding scheme covering the Certificate message has to address compression within its design, or disable it altogether. </ins> 6. It's been observed that a significant number of middleboxes intercept
Original text:
6. <del> 6.1. </del>  Create an entry, compress_certificates(TBD), in the existing registry for ExtensionType (defined in RFC5246). <del> 6.2. </del>  Create an entry, compressed_certificate(TBD), in the existing registry for HandshakeType (defined in RFC5246). <del> 6.3. </del>  This document establishes a registry of compression algorithms supported for compressing the Certificate message, titled

Reviewer comments:
I feel like we should provide a somewhat more specific guidance. "Server implementations MAY choose to negotiate certificate compression only in cases when the TLS version is 1.3 or newer"? (SHOULD is also fine, we should probably pick whatever level draft22 compat hacks use)
AFAICT draft22 doesn't use any specific RFC2119 words for the compat mode (it just says "can use" a bunch of times). Also, I think this is somewhat different in that there's no real change between TLSv1.2 and TLSv1.3 for compression (differently from the TLSv1.3 compat mode where the protocol actually slightly changes). So, knowing the risk, it should just be up to the server and the client to decide whether to use compression or not with TLS < 1.3 IMO.
Good point.

Revised text:
6.  <ins> It's been observed that a significant number of middleboxes intercept and try to validate the Certificate message exchanged during a TLS handshake.  This means that middleboxes that don't understand the CompressedCertificate message might misbehave and drop connections that adopt certificate compression. However this is not a problem when using TLS version 1.3 [draft-ietf- tls-tls13] and higher, due to the fact that the Certificate (and thus the CompressedCertificate) message is encrypted, preventing middleboxes from intercepting it. 7. 7.1. </ins> Create an entry, compress_certificates(TBD), in the existing registry for ExtensionType (defined in RFC5246).  <ins> 7.2. </ins> Create an entry, compressed_certificate(TBD), in the existing registry for HandshakeType (defined in RFC5246).  <ins> 7.3. </ins> This document establishes a registry of compression algorithms supported for compressing the Certificate message, titled
Original text:
The values in this registry shall be allocated under "IETF Review" policy for values strictly smaller than 64, and under "Specification <del> Required" policy otherwise (see RFC5226 for the definition of </del>  relevant policies).

Reviewer comments:
Addresses .
Just need to swap out RFC5226 with RFC8126.
Fixed by df35ba55dc4ffee1eb616898e044384782817a89, thanks!

Revised text:
The values in this registry shall be allocated under "IETF Review" policy for values strictly smaller than 64, and under "Specification  <ins> Required" policy otherwise (see RFC8126 for the definition of </ins> relevant policies).
Original text:
basic keep-alive function.  In contrast, Ping and Pong messages are a bidirectional exchange. <del> Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the </del>  recipient of a Ping or Pong message MUST ignore elective options it does not understand.

Reviewer comments:
Corrected title for (leaving open while we discuss examples) Corrected version for new since-draft section
It only has examples of Ping and Pong. (It would probably help to have an example of an initial CSM exchange.)
Or perhaps eliminate the examples? I note that RFC7252 does not include Option examples.
I'd rather do the work to include an initial CSM exchange. Just not sure I can get to that tomorrow. (This kind of example is counter-intimidating — after all the verbiage you see that it is all really very simple...)
I'm not sure that it was intimidating although I like counter-intimidating. It was certainly not a source of confusion during WGLC that then required clarification in examples. I worry about simply adding noise. And if pursued further, we should avoid Default-Uri-Host which would leave Max-Message-Size and Block-wise Transfer.
I corrected the title in . I'm won't fixing the suggestion for CSM examples based on my previous comment. This can be revisited if there's any related confusion during subsequent reviews.

Revised text:
basic keep-alive function.  In contrast, Ping and Pong messages are a bidirectional exchange.  <ins> Upon receipt of a Ping message, the receiver MUST return a Pong message with an identical token in response.  Unless there is an option with delaying semantics such as the Custody Option, it SHOULD respond as soon as practical.  As with all Signaling messages, the </ins> recipient of a Ping or Pong message MUST ignore elective options it does not understand.