Good point.
Maybe for an operator this bumps the API to a 'SHOULD'.
In a lot of cases a limited IoT device will be incapable of satisfying the requirements.
What I would like here is some means of delegating the authorization process off to another device that would have a more capable interface. Do we need to add a spec for this?
Cheers,
Christian
On 17-04-05 10:51 AM, Dave Dolson wrote:
This is OK if you only need to serve devices with browsers and attentive humans.
The API offers possibilities for automation in the device by making a formal data model (vs. HTML).
From: Captive-portals [mailto:[email protected]]
On Behalf Of Christian Saunders
Sent: Wednesday, April 5, 2017 12:38 PM
To: David Bird
Cc:
[email protected]
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"
The currently proposed solution has 3 components:
1. The ICMP component is used to detect a captive network.
2. The DHCP component is used to discover the address of the Captive Portal.
3. The API is an information service with a standardized interface that allows discovery and potentially remediation of the requirements for network access.
The ICMP and DHCP components are sufficient to resolve the redirection and HTTPS issue.
I would consider the API as an optional component - it might create some user experience benefits if the device developers and network operators choose to use it.
The difficulty with the API is having a way of codifying all of the possible network access requirements. I'm not sure this is reasonably possible.
Assuming that such a definition is possible, then there is some benefit to the common definition.
(It also strikes me that this definition would make a nice back end design for the Captive Portal itself.)
Cheers!
Christian
On 17-04-05 10:25 AM, David Bird wrote:
Edits in-line :)
On Wed, Apr 5, 2017 at 9:06 AM, David Bird <[email protected]> wrote:
A few more key benefits of the ICMP approach :
- Capport detection is made easier for the client, even when RFC 7710 (or any API) is
NOT implemented (as long as the NAS is Capport compliant).
- "Signaling" can be done by different components (NAS, iptables, rate-limiter, PCEF, etc), without (necessarily) needing to coordinate with a central service.
- In defining the RFC in how a NAS should handle blocking traffic for Capport compliant devices, we are also defining how the NAS should handle Legacy devices - which is, there is no difference - they both get ICMP Dest Unreach w/Capport
extension) - which is helpful.
_______________________________________________
Captive-portals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals
|