As discussed in the IETF hackathon/informal meeting, the consensus is to change expire-date (an absolute iso datetime) to seconds-remaining integer (named after bytes-remaining)

There is a missing come on the user-portal-url line ;-)

'vendor' can mean lots of things ... e.g. Cisco or Ruckus.

The API document should discuss behavior around link relations, etc.

Should we define an IANA registry for adding new keys?

We should look at adding to the base API document a JSON key to specify a URI for a vendor info page (store info, maps, entertainment, etc)

I don't think that we need this. 7710 gives us an entire URI, as can PvD.

Specifically in Section 3, "enforcement" section.

ORIGINAL:
"... a client sends an HTTP GET request."

PROPOSED:
"... a client sends an HTTPS GET request."

The draft currently specifies a deadline as an absolute time. Experience with implementation showed that time remaining (in seconds) was easier to implement and less subject to the vagaries of clock differences.

To meet the architecture requirements.

Boolean value to add. Suggested names have been remediation-supported and can-extend-session.

Hi,

The current documents treat captivity as a transient phase with a well-defined exit process. Often, the users stay in a "captive" mode longer, and they can still access certain resources/websites/apps. Airplanes and out-of-balance mobile users are certain examples.

It is well-known that the network has challenges to enforce desired policies, and falls back into using hacks like DNS/SNI/IP allow lists.

Is the group interested to examine the enforcement aspect, and how the client's OS can assist such enforcement so that they can still work with DoH, ECH etc? We've been looking at use cases that require some sort of "network authorization", and this might be relevant.

Thanks,
Yiannis

p.s.: I tried twice to subscribe to the IETF mailing list but got no confirmation e-mail or anything. Please let me know if you prefer to move this discussion there and if you could check pending subscription in the mailing list.

Section 3.2 "JSON keys" about the "bytes-remaining" should probably be clear on whether the bytes are counted at layer-2 excluding management traffic or layer-3 bytes

Should we hold the addition of this until we have something that depends on it being in the API?

In the "Server Authentication" section, there is a mention about letting OCSP go through the captive portal before being authorized, so, there should also be mention of NTP or any other time-synch protocol.

We should really say this.

(h2 server push might help automate this...)

We identified a need to be clearer here that the value counted as both up and down (added together) and that we needed to explicitly say that the count includes the IP packet header.

We should consider flipping the JSON key for permitted to its opposite to match the architecture document description

The updated reference should be, I believe, https://tools.ietf.org/html/rfc8259 .

application/json is fine in the general sense, but if you want to ever do things like versioning, then a media type is important. Crib from geojson if you want a recent example.

As David Bird pointed out, we should describe the model we assume for API server authentication. Then we need to describe the requirements on this.

An important point here is that CRL or OCSP checking are likely to fail for a captive UE. A recommendation for servers to use OCSP stapling is likely necessary (whitelisting CRL or OCSP servers is probably workable, but OCSP stapling is a far superior solution).

Having per-client information (esp. the HMAC key) means that you need to have text about ensuring that the information is kept private. That means a strong admonishment for Cache-Control: private at a minimum.

I know there has been a lot of discussion about User Equipment Identity, and I'm not sure what the conclusions are, but I think this API document needs to explain how it must work.

The example says Cache-Control: private but there are no paragraph statements about what policy should be used.
I think we want caching disabled, since the result may change with each GET.

That might make the api useless today, but if we ever want a non-human to use this api it might be annoying.