jiebi/CodeConvo huggingface dataset:
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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.
Code change:
Not quite. It specifies secure bootstrapping of the individual nodes. It's RFC 8994 that bootstraps the ACP.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <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.
Code change:
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'

Related discussion:
text: <del> CAPPORT Architecture </del> <ins> Captive Portal Architecture </ins> 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> <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.
Code change:
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'

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <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:
Code change:
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.

Related discussion:
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> <ins> This document only considers devices with web browsers, with web </ins> applications being the means of satisfying Captive Portal Conditions. <del> An example interactive User Equipment is a smart phone. </del> <ins> An example of such User Equipment is a smart phone. </ins> The User Equipment:
Code change:
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.

Related discussion:
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> <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 <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> <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 <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> <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
Code change:
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.

Related discussion:
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.
Code change:
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."

Related discussion:
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> <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
Code change:
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!

Related discussion:
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> <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
Code change:
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!

Related discussion:
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
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <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>