[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] API / ICMP for status and remaining time
I would say please don't hack stuff into ICMP.
It will be easier for client platforms (mobile devices, laptop OSes,
...) to whip up a simple REST app than update ICMP handling. Yes the
latter is certainly doable, but a REST API will be so much more
capable and future-proof, IMHO.
If this working group worked to spec v1 of the API that would make
sense to me. :)
On 31 August 2016 at 06:49, Alexander Roscoe <[email protected]> wrote:
> I am looking at the mechanisms to communicate captive portal states to
> users. I think a RESTful API would be viable candidate for
> communicating this information. The same URL from RFC7710 or the URL
> given by the 302 redirect could be used to as the endpoint for this
> service as well. Clients could reach out to this endpoint to get
> status such as "Time Remaining" or "TX/RX transferred". RESTful
> interfaces can be easily setup and can be easily extended to add new
> features.
>
> Along side REST, I was looking at the ICMP as a conduit to transmit
> this information as well. Information could be pushed to the clients'
> device and then digested rather than pulled like a RESTful protocol.
> I think an implementation of this setup could work well on a
> deployment where the AAA server resides on the same system as the
> gateway because the information in the ICMP is easily accessible.
> When the AAA server exists on another system it may pose a problem.
> For example, many networks that use captive portals block external
> ICMP messages and/or NAT devices to client, therefore the gateway
> would need to proxy these packets. This adds more complexity to the
> network design. Also, ICMP message would be very rigid and not as
> extendable as a RESTful service. Maybe rigid might be a good thing?
>
> Thoughts? Did I miss another type of conduit to transfer status...
> excluding SOAP :)
>
> --
> Alexander Roscoe
> 484-716-9048
>
> _______________________________________________
> Captive-portals mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/captive-portals