Original text:
Abstract This document describes an HTTP API that allows hosts to interact <del> with a Captive Portal system on a local network. </del>  1. This document describes a HyperText Transfer Protocol (HTTP) Application Program Interface (API) that allows hosts to interact <del> with a Captive Portal system on a local network.  The API defined in this document has been designed to meet the requirements in the Captive Portal Architecture I-D.larose-capport-architecture. Specifically, the API provides: </del>  The state of captivity (whether or not the host has access to the Internet) are blocked by the captive portal This document is focused on the second step.  It is assumed that the <del> location of the Captive Portal API server has been provisioned as part of the first step.  The mechanism for discovering this value not covered by this document. </del>  3. 3.1. <del> In order to communicate with the captive portal API server, the URI provisioned to the host SHOULD use the form of a well-known URI RFC5785 ending with the string ".well-known/captive-portal.json".  If this suffix is not included in the URI already provisioned, a host SHOULD append the suffix when communicating to the server. The Captive Portal API MUST be accessed using HTTP over TLS on TCP port 443 (HTTPS) RFC2818. </del>  For example, if the Captive Portal API server is hosted at <del> example.org, the URI of the API would be: "https://example.org/.well- known/captive-portal.json". </del>  3.2. server "user-portal-url" (required, string): provides the URL of a web <del> portal that can be presented a user to authenticate </del>  <del> "expire-date" (optional, datetime): indicates the time at which the Captive Portal is expected to close </del>  "bytes-remaining" (optional, integer): indicates the number of <del> bytes left, after which the Captive Portal is expected to close </del>  Note that the use of the hmac-key is not defined in this document, but is intended for use in the enforcement step of the Captive Portal 5. <del> This document defines one ".well-known" URIs using the registration procedure and template from Section 5.1 of RFC5785. 5.1. URI suffix: captive-portal.json Change controller: IETF Specification document(s): This RFC Related information: None </del>  6.

Reviewer comments:
Removed language for /.well-known URI. Made serving over port 443 a SHOULD requirement. Other editorial changes
Added your updated language, should be good to go.
I don't think that we need this. 7710 gives us an entire URI, as can PvD.
I agree that we can use the URI from the DHCP option or from PvD. The reason I went this route was to avoid the scheme that was in the API draft to start with, which seemed to be: If you access the 7710 URI with a GET, you'll receive the HTTP for the user interactive portal If you access the 7710 URI with a POST, you'll get the JSON API That seemed problematic (a) because it implies the user portal and API are co-located and (b) it seemed overly complex. Do you have a preference for what methods are valid to access the JSON API, and whether we should specify that the URI needs to be JSON? My concern was that if the DHCP option or whatever pointed to something that was clearly .html, something's wrong, and using a well-known JSON URI to compare against would be a way to detect that.
NAME Thoughts on the method for fetching the JSON API, or if that's a non-issue?
Let's take this to the list.
PR fixes the well-known URI language. For now there is indication of Accept and Conent-Type header usage but we haven't explicitly called it out until we get a final decision. We can close this issue though.

Revised text:
Abstract This document describes an HTTP API that allows hosts to interact  <ins> with a Captive Portal system. </ins> 1. This document describes a HyperText Transfer Protocol (HTTP) Application Program Interface (API) that allows hosts to interact  <ins> with a Captive Portal system.  The API defined in this document has been designed to meet the requirements in the Captive Portal Architecture I-D.ietf-capport-architecture.  Specifically, the API provides: </ins> The state of captivity (whether or not the host has access to the Internet) are blocked by the captive portal This document is focused on the second step.  It is assumed that the  <ins> location of the Captive Portal API server has been discovered by the host as part of the first step.  The mechanism for discovering the API Server endpoint is not covered by this document. </ins> 3. 3.1.  <ins> The URI of the API endpoint MUST be accessed using HTTP over TLS (HTTPS) and SHOULD be served on port 443 RFC2818.  The host SHOULD NOT assume that the URI for a given network attachment will stay the same, and SHOULD rely on the discovery or provisioning process each time it joins the network.  Depending on how the Captive Portal system is configured, the URI may be unique for each host and between sessions for the same host. </ins> For example, if the Captive Portal API server is hosted at  <ins> example.org, the URI's of the API could be: "https://example.org/captive-portal/api" "https://example.org/captive-portal/api/X54PD" </ins> 3.2. server "user-portal-url" (required, string): provides the URL of a web  <ins> portal that can be presented to a user to interact with </ins>  <ins> "expire-date" (optional, string formatted as RFC3339 datetime): indicates the date and time after which the host will be in a captive state </ins> "bytes-remaining" (optional, integer): indicates the number of  <ins> bytes left, after which the host will be in a captive state </ins> Note that the use of the hmac-key is not defined in this document, but is intended for use in the enforcement step of the Captive Portal 5.  <ins> TBD: None </ins> 6.