Re: [Captive-portals] Requirements for "captive portal closed" notifications

Indeed... a long-tail of purposes.

We should NOT intentionally limit the protocol because of a single
scenario, which somehow is considered a non-starter for the feature (of
including the traditional ICMP payload).

On Wed, Mar 21, 2018 at 7:10 AM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Aside from the business model of upgrades, there is also the academic
> institution situation which you mention, where captive portals are often
> used.
>
> The student or faculty must login.
> It's not just for WIFI (there may be an additional layer of security
> there!).
>
> There may be filters which will prevent:
>
> Nicolas Mailhot <nicolas.mailhot@laposte.net> wrote:
>     > Most walled gardens will want something like 'free access to
>     > pr.institutionalsite.com/intranet.mybusiness.net/library.school.com
> ',
>     > downloading gigs of videos from youtube requires autorisation,
>     > sex.xxx.com, playingatwork.net and examsolutions.cheater.org are
>     > forbidden.
>
> And there may be different responses needed for:
>
> 1) a specific login/upgrade/override code (from the teacher) will allow
>    access to X.   I think that this is common.
>
> 2) no matter what you enter, you won't get to sex.xxx.com.
>    I don't think we need anything new for this, ICMP Admin prohibit is
> good.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>