[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Captive-portals] How to talk about filtering/network management (was 102 minutes)



(I thought this needed a new thread.)

On Sat, Jul 21, 2018 at 5:30 AM Michael Richardson
<[email protected]> wrote:
> > darshak - logged in is not necessary a binary state - what if the
> > network wants to block netflix
>
> It is noted that we can't get consensus.  Some questions:
> 1) is that we can't get consensus on whether this is a good idea?
> 2) that we can't get consensus on how to signal this?
> 3) on how to represent this in the protocol?

Good question.

My reading is that it could be all three, but my hope is that it turns
out that we can agree to a weaker form of signaling that will allow us
to avoid having to agree on 1, even if that is what lies at the root
of this particular issue.

My reading of the conversation thus far is that we might get consensus
to make this part of the communication between the network operator
and a human.  That is, the network operator is expected to use the web
page to communicate this sort of information rather than to encode it
in the sort of terms that we would express in something as precise and
harsh as JSON.

As David mentions here and on the other thread, the ways in which the
network access you get and the network access you assume you have (or
each of us might assume is ideal) differ are virtually innumerable.
Blocking of access to certain destination is not the only thing that
might be considered: rate limiting, path selection, quality of
service, packet markings, and all sorts of variations are possible.

The IAB attempted to look at this problem a while back with RFC 4084 -
https://tools.ietf.org/html/rfc4084 - which was mentioned in the
meeting.  That might be a useful reference in any text that addresses
this point.  Not because the taxonomy there is useful (it's long since
been overtaken by events), but because it helps illustrate the
complexities involved.

In writing this, I realize that this conclusion would be something of
a cop-out on our part.  In other words, lacking consensus on the
fundamental issue, we instead to shift the responsibility to the
individual least able and empowered in this entire transaction.  While
acknowledging that flaw, the benefits here could still outweigh that
negative.  We might not fix the underlying problem, but we can still
fix the technical side-effects of it (attempts to MitM HTTPS, lack of
clarity at the UE end, etc...).  I'm guessing here, but it's possible
that attempting to use this work as a means of forcing people to
change their practices is more likely to result in the work we produce
being roundly ignored.

> I think that it's useful to clearly state what is going to be out-of-scope.
> (and I think that we really do need this)

I opened https://github.com/capport-wg/architecture/issues/13 during
the meeting to track this. You weren't the only one to realize this (I
won't claim credit, but can't remember who to give credit to - you can
try the recording if you like).

Thanks,
Martin (not a chair at this time, though the chair part would
definitely like to see this resolve)