[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] Arguments against (any) Capport "API"
> On 10 Apr 2017, at 12:53 pm, Erik Kline <[email protected]> wrote:
>
>
>
> On 8 April 2017 at 04:54, Michael Richardson <[email protected]> wrote:
>
> David Bird <[email protected]> wrote:
> > portal (or when the venue evaded your detection). Maybe the captive
> > portal networks wants to offer these services in their walled
> > garden... and it is likely the user would be happy about that
> > (provided they selected the network on purpose).
>
> Consider a school that uses Google Apps (like my sons').
>
> They run a somewhat loose firewall that blacklists stuff; but probably would
> be better off to whitelist things.
>
> The ICMP reply could very well be used to trigger the teacher override.
>
> This is an interesting point. We should consider what types of access restriction are in scope.
>
> Consider zero-rating, for example. Should the aim be to provide a general hint of network restriction, or on a per-destination basis?
Our charter is expressed in terms of authorization for network access. I could see providing context about the quality of the Internet connection (a la BCP104), but allowing destination-by-destination granularity has some pretty significant potential impact; it will basically be giving the IETF's blessing to zero-rating, and in some markets that's a very contentious topic.
So, we need to proceed carefully. IMO, we don't need to provide a per-destination capability to meet the charter, and doing so could add significant risk to an already risky endeavour.
Cheers,
--
Mark Nottingham https://www.mnot.net/