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

Discussion:
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> <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
Change:
Thanks for doing this! I've left a few minor comments.
Just for transparency. Erik and I discussed this and made a few editorial changes.
thanks, was just trying to work on the changes here
Based on discussion in Singapore, the group decided to recommend (not require) that URLs use names that can be resolved from the public DNS (no split horizon, etc...). The content served from those URLs should also not be dependent on the network path, but instead the URL would include all information necessary to produce the resource.
i remember we were talking about primarily venue URL should be context free however, the architecture doc does not mention the venue URL (only portal URL) which section shall we add this context-free please? (maybe in section_pvd?) shall we also mention this in the api doc?
I think that NAME might want to think about what to include once we have text here. The text can be generic. I would suggest a new Section 3.5 as this relates to identification of UE. That is, you say that information presented in the API - and in particular URLs - need to include identification UE information. In particular, any information that is used from this context should not depend on ambient information, such as the remote address on a connection, as this information might be used by the UE on a different network interface. For example, a user might access venue information URLs from another network. You might also then mention that this might expose the service to spoofing or replay of that information in those cases. This might mean that though the URL might "work", it might not present all options. For instance, payment options might not be offered, or if they are, warnings might be shown that the payment is not for the current connection.
Thanks for doing this. This seems to accurately capture the outcome of the discussion we had.

Discussion:
addresses on a single link.  In such cases, identification could be performed by subnet, such as the /64 to which the IP belongs. <ins> 3.4.3. The URLs provided in the API SHOULD contain all the information necessary to render the resources requested: the resources should not depend on ambient information, such as remote address on the connection.  This is to ensure that the content served from these 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 expected to be resolved using public DNS. Though a URL 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. URLs could include some means of identifying the User Equipment in the URLs.  However, including unauthenticated User Equipment identifiers in the URL may expose the service to spoofing or replay attacks. </ins> 4. This section aims to improve understanding by describing a possible
Change:
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.

Discussion:
2.2.1. A standard for providing a portal URI using DHCP or Router <del> Advertisements is described in RFC7710.  The CAPPORT architecture </del> <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
Change:
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

Discussion:
2.2.1. A standard for providing a portal URI using DHCP or Router <del> Advertisements is described in RFC7710.  The CAPPORT architecture </del> <ins> Advertisements is described in RFC7710bis.  The CAPPORT architecture </ins> 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
Change:
URL provides a definition of "Global DNS" to which we might want to link.
Thanks!

Discussion:
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> <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
Change:
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.

Discussion:
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:
Change:
Does this also need to update the boilerplate text that defines SHOULD, MUST, etc?
forgot to mention that, but the draft is already updated to use 8174 boilerplate
In the paragraph starting at line 633, we say: In particular, " Consequently, any solution using the IP address should proactively" and "the components of the architecture must remove or update their" I think we should either capitalize these two or rephrase them.
Aside from my one comment, lgtm. I don't think the intention of the issue was to rephrase everything that used lowercase, but to make sure that we capitalized everything we needed to.
changed the 2 to capital case
lgtm, thanks.
A scrub for these to determine which are really requirements is a good idea. Also, update SS1.1 to use RFC 8174 boilerplate.
looks OK to me

Discussion:
Another consideration related to uniqueness of the User Equipment is that if the attached User Equipment changes, both the API Server and <del> the Enforcement Device must invalidate their state related to the </del> <ins> the Enforcement Device MUST invalidate their state related to the </ins> User Equipment. The Enforcement Device needs to be aware of the physical interface,

However, it may be possible to spoof the IP address, particularly for malicious reasons where proper functioning of the network is not necessary for the malicious actor.  Consequently, any solution using <del> the IP address should proactively try to prevent spoofing of the IP </del> <ins> the IP address SHOULD proactively try to prevent spoofing of the IP </ins> address.  Similarly, if the mapping of IP address to User Equipment <del> is changed, the components of the architecture must remove or update </del> <ins> is changed, the components of the architecture MUST remove or update </ins> their mapping to prevent spoofing.  Demonstrations of return routeability, such as that required for TCP connection establishment, might be sufficient defense against spoofing, though this might not

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. <del> The API must ensure the integrity of this information, as well as its </del> <ins> The API MUST ensure the integrity of this information, as well as its </ins> confidentiality. 7.4.
Change:
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!

Discussion:
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
Change:
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.

Discussion:
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> <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.
Change:
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.

Discussion:
<del> Transport Layer Security (TLS) Certificate Compression </del> <ins> TLS Certificate Compression </ins> 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> <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 <del> to reduce the amount of data exchanged during a Transport Layer Security (TLS) handshake. </del> <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
Change:
When running idnits, it reports a couple of issues: RFC1950 and RfC7932 are the zlib and brotli RFCs. I'm guessing the way to fix this would to remove the related MUSTs and downgrade the references, though I haven't come up with appropriate wording yet. /cc NAME (any suggestion?)
fixes a couple more errors that are not listed here btw.
Note that downref "nits" can be handled via documented procedures in . In summary, we can identify them in the IETF LC (when we get there) and see who objects to referring to an informative RFC from this draft, which is intended for standards track. For zlib there are a ton of these already and it looks like somebody just didn't update the downref registry (i.e., I suspect there will be no strenuous objections from anybody). For brotli, it's newer but I am not too worried about the uproar. I'd just leave the MUST and the normative references in.
Ok, thanks NAME I'll close this then.

Discussion:
(compress_certificate(27)), which can be used to signal the supported compression formats for the Certificate message to the peer. Whenever it is sent by the client as a ClientHello message extension <del> (I-D.ietf-tls-tls13, Section 4.1.2), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (I-D.ietf-tls-tls13, Section 4.3.2), it indicates the support for compressed client certificates. </del> <ins> (RFC8446, Section 4.1.2), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (RFC8446, Section 4.3.2), it indicates the support for compressed client certificates. </ins> By sending a compress_certificate extension, the sender indicates to the peer the certificate compression algorithms it is willing to use

that adopt certificate compression.  Because of that, the extension is only supported in the versions of TLS where the certificate message is encrypted in a way that prevents middleboxes from <del> intercepting it, that is, TLS version 1.3 I-D.ietf-tls-tls13 and higher. </del> <ins> intercepting it, that is, TLS version 1.3 RFC8446 and higher. </ins> 7. 7.1. Create an entry, compress_certificate(27), in the existing registry <del> for ExtensionType (defined in I-D.ietf-tls-tls13), with "TLS 1.3" column values being set to "CH, CR", and "Recommended" column being set to "Yes". </del> <ins> for ExtensionType (defined in RFC8446), with "TLS 1.3" column values being set to "CH, CR", and "Recommended" column being set to "Yes". </ins> 7.2. Create an entry, compressed_certificate(25), in the existing registry <del> for HandshakeType (defined in RFC5246). </del> <ins> for HandshakeType (defined in RFC8446). </ins> 7.3.

over the open Internet. The procedures for requesting values in the Specification Required <del> space are specified in I-D.ietf-tls-iana-registry-updates. </del> <ins> space are specified in RFC8447. </ins>
Change:
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

Discussion:
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
Change:
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.

Discussion:
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
Change:
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.

Discussion:
6. <del> 6.1. </del> <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). <del> 6.2. </del> <ins> 7.2. </ins> Create an entry, compressed_certificate(TBD), in the existing registry for HandshakeType (defined in RFC5246). <del> 6.3. </del> <ins> 7.3. </ins> This document establishes a registry of compression algorithms supported for compressing the Certificate message, titled
Change:
Addresses .
Just need to swap out RFC5226 with RFC8126.
Fixed by df35ba55dc4ffee1eb616898e044384782817a89, thanks!

Discussion:
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> <ins> Required" policy otherwise (see RFC8126 for the definition of </ins> relevant policies).