Re: [Captive-portals] Arguments against (any) Capport "API"

[Christian Saunders <[e-mail]>]

Does WISPr support all of the use cases?  Is there a publicly available source for the WISPr XML spec?

Cheers!

Christian

On 17-04-05 11:15 AM, David Bird wrote:
I agree with that... but, to be clear, it really is just an improvement on WISPr XML, and with WISPr XML already, not only used, but used to make money, the reasons for supporting this API MUST be inline with the venue/Operator needs. 'Automating login' (as a focus for the API) quickly becomes venue / regional / legal / vertical / application / access policy dependent.. Not to mention, I question the value for the user in making it super simple for their devices to auto-login into public access networks (without clear user intent). This seems irresponsible, on our part, when there are solutions out there already that do automate this login, but only after taking extra security measures (presumably, hotspot aggregators conceal your identity when roaming, and their Apps can do more things).

On Wed, Apr 5, 2017 at 9:51 AM, Dave Dolson <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Christian Saunders
Sent: Wednesday, April 5, 2017 12:38 PM
To: David Bird
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/captive-portals