(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) _______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
