On Tue, Jun 30, 2015 at 2:10 AM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 23 June 2015 at 11:26, Warren Kumari <war...@kumari.net> wrote: >> We would like to get a discussion going on some *strawman* charter text. > > I realize that this might be a little controversial, but I really > don't like the term "captive portal". > I think that a valuable product > of this working group would be a thing that accomplishes the goal that > captive portals set out to achieve, without the MitM.
Yup. +1 <aol>me too</aol> I'd like to stick with the term "captive portal" for now, simply because: A: that is the name on the BoF / what people think of this as and B: the terms still seems to make sense to me -- even if there is no MitM, users will still be 'captive' (imprisoned or confined) until they convince the network that they need to get out. The 'portal' bit I cannot really justify, other than the game (https://en.wikipedia.org/wiki/Portal_(video_game)), which has someone who want something (cake and grief counseling) but is being thwarted by technology :-) > > Currently, this charter bemoans the current status where MitM is the > only real option, but does not set out to create a situation that is > materially different. I'd like to see it say something more > definitive about this. (And no, I'm not in denial; I expect that > networks will continue to MitM, but we'll never be rid of the beast > until we have a viable alternative). Hmmm... I hadn't intended the charter to be so whiney about the interception bit. I wanted the charter text to be longer than just: ---------- The Captive Portal (CAPPORT) Working Group will define a standard mechanism for clients to interact with Captive Portals, including how to discover and connect, and how to communicate with it to obtain status information such as remaining access time, purchased bandwith class, etc. This working group will seek participation and input from browser / operating system vendors, captive portal developers and operators. One of the known challenges is that some captive portal operators may not want to use a standard interaction protocol, preferring to perform more intrusive interception and interactions. We are hoping that the benefits to CP standardization outlined here are sufficient to not only encourage input from CP developers and operators, but also aid in deployment. ----------- We are (probably) asking for the formation of a WG, and I wanted charter text that explains a bit more about what the issues are, and explains more about what we will be doing. Perhaps the above is long enough? Does it need some more text / background? Any proposed text gratefully accepted... > > --- > I understand that the aim is to solicit human input as a prerequisite > of authorizing network access. A secondary goal is to provide > programmatic access to status information, primarily time remaining, > in support of knowing how to get back to the first part. > > Those goals could be (minimally) achieved by discovering two pieces of > information: > - the time remaining on the network > - where to direct human eyeballs if a change to this time is desired Yup. I think the fact that there *is* a widget that blocks access until it is satisfied is also needed. This is very similar, but subtly different to your first bullet.... > > There is some additional information that could be interesting later, perhaps: > - programmatic access to login/logoff functions (useful if time-based > charging is involved) Yup. This will also be needed for devices that have no UI. > - information about network paths that are not gated (though I'm > struggling a little to justify this, it's a common enough feature, we > might like to support it, noting that this is usually discovered via a > portal page, which could be sufficient). Hmmm. interesting... W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
