Thanks Darshak and Tommy, this is really helpful.
Some comments:
In 2. Workflow: Does it make sense to reorder 2) and 3)? It would seem 'Enforcement' should come before determining status (of said enforcement) and how to proceed. I would argue that the UE might as well try to use the network and wait for the network to respond (e.g. with Enforcement and/or routing notifications/errors. Indeed, the UE sorta already *did* this if it resolved DNS and checked certificate status of the API server hostname.
In 3.1 URI of Captive Portal endpoint, I think we must go beyond making TLS a MUST --- we need to define how trust is handled. We must require the API client to validate the hostname, present that hostname to the user for acknowledgement. Or, are we explicitly saying that TLS is for privacy and not security? (e.g. that we really don't care what the server cert is... just that the cert is consistent for that location / domain?). Is the client expected to check revocation lists?
In 3.2, ' "permitted" (required, boolean): indicates whether or not the Captive Portal is open to the requesting host ' is confusing... does it mean the UE is subject to a captive portal? I dislike how boolean this is! Why does it have to be all or nothing (especially if ICMP is providing enforcement notification?)
Also in 3.2, I'm not sure about the time/data remaining info.. Is the expectation that the client keeps polling? (never goes idle on any network?) Is the expectation that the UE will break connections after it sees this API expire timer or counter, or shall the (smart) UE wait until the network notification (ICMP) ?
I think it would be idea to keep ICMP focused on network notification and we can use the API more for validation and improving the security (and user interaction) of ICMP.
Cheers,
David